PublishToEnvironment: Deployment not tracked against PR branch when using appVersion: PR_<ID>

[StefanMaron]

Description

When using the PublishToEnvironment workflow to deploy a PR from the main branch (using appVersion: PR_<PR_ID>), the deployment is registered against the workflow's trigger ref (main) instead of the actual PR branch being deployed.

This causes GitHub's PR interface to show "This branch has not been deployed" even though the PR has been successfully deployed.

Current Behavior

1. Run PublishToEnvironment workflow from main branch
2. Set appVersion: PR_123 to deploy a specific PR
3. Workflow successfully deploys the PR code
4. GitHub creates deployment record against main branch (workflow trigger)
5. PR AL-Go for on-prem BC? #123 shows "This branch has not been deployed" ❌

Expected Behavior

When appVersion matches pattern PR_<ID>:

1. Workflow should detect this is a PR deployment
2. Fetch the PR branch name via GitHub API
3. Create deployment record against the PR branch (not workflow trigger ref)
4. PR shows correct deployment status ✅

Why This Matters

Common use case: Running deployments from main with environment protection rules, while deploying feature branch code. This pattern allows:

• Centralized deployment control from main branch
• Environment protection rules enforcement
• PR-based artifact deployment
• Clear deployment visibility in PR interface

Without proper deployment tracking, teams lose visibility into which PRs have been deployed to which environments.

Proposed Solution

Modify PublishToEnvironment.yaml Deploy job to:

1. Add deployments: write permission
2. Before deployment, detect if appVersion matches PR_<ID> pattern
3. If yes, fetch PR branch ref via GitHub API
4. Create explicit deployment record against PR branch using GitHub Deployments API
5. Update deployment status after deployment completes

This preserves all existing functionality while correctly tracking PR deployments.

Workaround

Users can manually add deployment tracking logic to their workflows (see solution above), but this should be built into AL-Go's template.

Environment

• AL-Go Version: v8.1 (issue also present in v8.2)
• Template: Per Tenant Extension (PTE)
• Workflow: PublishToEnvironment.yaml

Related

GitHub's environment: key automatically creates deployments against the workflow trigger ref, which is the root cause of this issue. Explicit API calls are needed to override this behavior for PR deployments.

[StefanMaron]

Additional Context: Current Workaround and Its Limitations

There is a workaround to achieve correct PR deployment tracking, but it's cumbersome:

Current Workaround:

1. Update environment's allowed deployment branches to include the feature branch
2. Run the deployment workflow from the feature branch (not main)
3. Specify appVersion: PR_<ID>
4. Deployment is then correctly registered against the PR branch

Why This Is Problematic:

• Manual configuration overhead: Each feature branch requires updating environment settings
• Branch pattern complexity: Depending on branch naming conventions, it can be difficult to configure rules that cover all feature branches (e.g., feature/*, bugfix/*, hotfix/*, developer-specific patterns)
• Security trade-offs: Loosening environment branch restrictions to accommodate all feature branches may weaken deployment controls
• Doesn't scale: Teams with frequent feature branches would constantly manage environment settings
• Error-prone: Easy to forget to update environment settings, leading to deployment failures

Ideal Solution:

Run deployment from main (with proper environment protection) while automatically tracking deployment against the actual PR branch being deployed. This maintains security controls while providing accurate deployment visibility.

This reinforces why built-in support for PR deployment tracking in the template is valuable - it eliminates the need for manual environment configuration changes and preserves deployment security patterns.

[spetersenms]

Hi @StefanMaron, thanks for pointing this out, I can see why this is an issue. I have made a test locally based on your suggestion and that seems to work nicely, just be aware that the automatically created deployment against main would still exist, but be deactivated. There is the option to delete it, but I think it would be best to keep it deactivated to ensure proper audit trails and minimize risk of deleting something wrong in error.

[StefanMaron]

@spetersenms thanks for confirming. I think that would not be an issue.