Deployment protection rules for issue comment trigger #388

Activity

1. EResman

   added

   questionFurther information is requested or the issue is a questionFurther information is requested or the issue is a question

   on May 5, 2025
2. GrantBirki commented on Aug 18, 2026

   

   GrantBirki

   on Aug 18, 2026

   Last edited by GrantBirki

   Contributor

   More actions

   @EResman thanks for the report, and sorry this sat unanswered. Your diagnosis is correct. GitHub gives an issue_comment workflow the default branch as GITHUB_REF, and job-level environment rules are evaluated before any steps start. Branch Deploy therefore cannot make that check see the PR's release/* branch.

   Branch Deploy later creates its own deployment using the PR head ref, but API-created deployments do not run GitHub Actions job-level environment protection rules. We ran into the same boundary in #352.

   If the job-level environment is only needed for secrets or variables, use the split-environment pattern:

   environment:
     name: production-secrets
     deployment: false

   Configure that secrets-only environment to permit main, then keep environment: production on Branch Deploy itself. deployment: false avoids creating an extra deployment record, but it does not make the native release/* rule evaluate the PR branch.

   If release/* is a hard requirement, then yes: today you need a trusted preflight check that fetches the PR head ref through GitHub's API and rejects non-matching branches before Branch Deploy runs.

   I think the clean long-term feature would be an opt-in, per-environment source-branch allowlist in Branch Deploy. I am going to leave this issue open to track that for now...