Custom deployment protection rules: callback scope for sequential jobs and run attempts

[lorisinvento-del]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Webhooks

Body

I’m trying to understand the supported behavior of GitHub App custom deployment protection rules when two sequential jobs use the same protected environment and App rule.

This concerns custom App callbacks, not required-reviewer approvals. It is a documentation/behavior clarification, not a report of a confirmed approval bypass.

The simplified workflow is:

job_a → job_b

Both jobs reference the same environment; job_b depends on successful completion of job_a. We need a separate authorization decision for each job.

The documented callback identifies the workflow run and environment:

POST /repos/{owner}/{repo}/actions/runs/{run_id}/deployment_protection_rule

{
  "environment_name": "protected-environment",
  "state": "approved",
  "comment": "Decision for the current request"
}

I have four related questions:

1. Request-to-job correlation
   Before approving a deployment_protection_rule webhook request, how can the App identify the exact pending job and run attempt that generated it? Is correlation through the webhook’s deployment ID and the Checks/Actions APIs supported and available before approval? Which fields and permissions are required?

2. Sequential jobs sharing an environment
   Does GitHub require a separate custom-rule decision for each sequential job? What determines which pending request the callback affects, given that it specifies the run and environment rather than a job ID or attempt?

3. Delayed callbacks and webhook redelivery
   If job_a has been approved and job_b is now waiting, what happens to a delayed or duplicate approval callback originally prepared for job_a? Would GitHub reject it, and what determines its scope?

4. Workflow reruns
   Since a rerun retains the run ID while incrementing the attempt, what happens to a callback associated with an earlier attempt? How should the App associate the incoming webhook with its originating attempt rather than merely reading the latest attempt?

I have consulted the custom protection-rule documentation and the callback REST reference, but haven’t found an explicit answer covering this scenario.

Any documentation pointers or first-hand experience would be appreciated, particularly clarification of what is supported behavior versus an observation from a particular workflow.

[stefisha]

From the current API, I don't think you can safely treat the approval callback as being scoped to a specific job or run attempt.

The approval endpoint only takes the run_id and environment_name. There is no job_id or run_attempt in the callback request, so GitHub does not give the App a way to explicitly say "approve job_a from attempt 1."

For your case, I would handle each deployment_protection_rule webhook as its own authorization request and store the information from that webhook before sending an approval. I would also use the webhook delivery ID for deduplication so a redelivered webhook doesn't cause the same decision to be processed twice.

For reruns, I would avoid approving based only on run_id, since the same run can have another attempt. Check the current workflow/job state through the Actions API before approving and reject/ignore anything that no longer matches the request you originally received.

So for the four points:

1. There doesn't appear to be a documented way to target the callback to an exact job_id.
2. Each job reaching the protected environment can trigger the protection rule, so treat each webhook as a separate request.
3. Make webhook processing idempotent and don't blindly replay an old approval.
4. Store the request context when the webhook arrives and verify the current run/job state before responding, especially after a rerun.

If you require a guaranteed separate authorization for every individual job/attempt, I wouldn't rely on run_id + environment_name alone. The current API doesn't seem to document that level of callback scoping, so GitHub Support would probably need to confirm the exact behavior for delayed callbacks and reruns.

If this resolves your question, please mark it as the answer. 🙂