Promotion path
Trace the code released through branches, environments and gates.
Availability
A promotion path shows how code reached a release, such as to to . Open a deployment's Promotion path or its Provenance timeline to inspect the hops, runs and reports behind it.
Same code across different commits
Squash and merge commits can change the commit SHA without changing the files. Same code means the git trees match. Changed lists the paths that differ. Same change on a different base means the promoted patch matches, but the target branch has other content; it does not mean the trees are equal.
A hotfix made directly on the release branch appears as a changed step that the walk stepped over. A back-merge, such as into , is marked so you can distinguish it from a forward promotion. The rules reject extra changes unless their Allow verified changes option accepts verified changes made only on the target branch. An unverified change never qualifies.
Declare the expected path
In a release policy, add Followed the declared promotion path, then choose Define the path in this policy under Path to check. Use 2 to 6 ordered steps. Each step names a branch, an environment or a gate, or a branch with either an environment or a gate. A step cannot name both an environment and a gate. A release off the last step fails.
One policy can cover every repository that follows the same SDLC. Bind it to a gate or attach it directly using the existing policy bindings. No organization default is needed.
Without a path in the rule, Prodgator uses the repository's path, then the organization's path, from Gates > Defaults. With none, the rule returns and holds an enforced gate. When a path is found, the declared-path result names its source: this policy, the repository setting or the organization setting. Its evidence includes .
Branch steps follow the pull request hops that promoted the content. A branch with an environment traces the run on its promoted merge commit and that run's deployment: it needs a successful deployment of that commit. Environment-only or gate-only steps need successful deployment hops in order. A gate step matches an environment the gate covers, including its exclusions. A successful older run on a different commit does not satisfy a missing deployment.
Fork pull requests never meet a branch step, even when their source branch has the expected name.
A step that names only an environment is only as strong as the provider's protection of that environment: anyone who can deploy to it from any branch meets the step. A gate step is stronger, because a gate adds its own approvers and policies. Use a branch plus an environment, or a gate, where the path must be enforced.
Steps show their run and deployment where known. Skipped means a required step was bypassed. Out of order means the content came through the wrong branch order. Pending waits for work still running; failed, missing and unknown steps cannot pass.
The release policy's declared-path rule reports a failed, skipped or unreadable step before a pending one. The compliance declared-path check currently waits on a pending step before reporting other step problems.
Reports for the release and the whole path
The Released code roll-up includes evidence from the release backward until the first changed or unknown hop. The Whole path roll-up includes every hop, including earlier code that changed. Tests, coverage and findings are tied to content rather than SHA alone.
Only trusted reports count. Duplicate sources count once. Coverage uses the lowest reported line percentage. Findings use the highest count per severity across distinct content groups, rather than adding the same finding at every promotion. The policy input exposes both roll-ups and per-hop evidence.
Provider coverage and limits
GitHub supplies git tree IDs and patch comparisons. GitLab tree IDs are computed from the root listing and checked against a known tree; a failed read is unknown. Bitbucket compares commit pairs. Azure Repos has no patch comparison, so Same change on a different base cannot be established there. Deployment environments come from the recorded deployments for each provider.
The walk is bounded to 12 hops, 4 promotions, 3 hotfix step-overs, a 90-day window and 40 provider reads. Candidate and evidence limits also apply. Path cut short means the walk could not establish the full history. Incomplete or truncated lineage cannot pass a promotion rule or check. Missing evidence is never proof that a required step succeeded.
Rules, templates and overrides
The four form rules check the declared path, unchanged code in selected environments, coverage along the path and findings along the path. Start with Promoted dev to uat to main unchanged or Follows the declared promotion path in the template gallery.
Compliance checks cover protected environments. Their declared-path check uses repository then organization settings, rather than a release policy's own path.
When a release must proceed past a result, use the existing override flow. A reason is required. The timeline records Promotion path check overridden, and the override is audited and notified to Org admins and members with compliance management or security triage permission. An override does not turn the failed check into a pass. Signed verification statements, including a result for an overridden check, remain planned work.