GitHub Actions adapter
Reference for the GitHub Actions adapter. Webhook events, status mapping, run controls, deployments and limits.
The GitHub adapter turns GitHub App webhook events into Prodgator runs, jobs, deployments and security alerts. To set it up, see Connect GitHub.
Events
| GitHub event | Prodgator record |
|---|---|
| Pipeline run | |
| Job (stage) of a run | |
| () | Deployment waiting on Prodgator's protection rule |
| Deployment review answered | |
| Deployment to any environment, gated or not: progress and result | |
| Security alert (Dependencies) | |
| Security alert (Code scanning) | |
| Security alert (Secrets) | |
| , | SPACE metrics and the status check |
Other events the App receives, such as , are acknowledged and dropped.
Webhook verification
All GitHub deliveries go to . GitHub signs each one with the App's webhook secret in the header. Prodgator computes HMAC-SHA256 of the raw body, compares it in constant time, and answers if it does not match. Deliveries are routed to your organization by the App installation they come from.
Status mapping
| GitHub status or conclusion | Prodgator status | Pipelines tab |
|---|---|---|
| Queued | ||
| Running | ||
| Awaiting approval | ||
| Awaiting approval | ||
| Success | ||
| Failed | ||
| Failed | ||
| Cancelled | ||
| , | Cancelled |
Run controls
and above can cancel a running run, re-run its failed jobs, or re-run one finished job (passed, failed or cancelled). Prodgator calls the GitHub Actions API with the installation token, which needs the App's Actions: Read and write permission. Cancel and re-run failed jobs are only offered for GitHub runs; GitLab runs get Re-run on each job.
Deployments
Prodgator records every deployment environment a workflow job deploys to (a job with ), whether or not anything gates it:
- A gated environment's deployment is recorded when its gate asks for approval ( or ), then follows its events.
- Any other environment's deployment is recorded from its first (, , , or ) and follows the rest. It is marked Not gated and has nothing to approve. It sends no notifications; the run's own result still does.
- Each deployment belongs to the workflow run whose job made it (from the event's , or the job link in ). Deployments that no Actions run made, such as ones created by a hosting provider through the API, are ignored.
- A run and environment have one deployment, however often GitHub delivers or repeats its events, and its status never moves backwards.
- Environments used only to hold variables or secrets (for example a environment on a build job) are deployments to GitHub too, so they are listed as well.
- A run on or whose workflow name contains , or and that reported no deployment environments of its own is recorded as a deployment to when it finishes.
Answering gates and rolling back:
- Prodgator's protection rule: answered by Prodgator's App through the deployment callback URL GitHub provides.
- Required reviewers: answered with the approver's own linked GitHub account.
- Rollback: re-runs the workflow run of the earlier successful deployment its button names, from the deployment environment's History. GitHub only re-runs runs from the last 30 days.
See Approve deployments.
Logs
Prodgator reads job logs through the GitHub API with the installation token, for failure classification and the run page.
Limits
- Matrix jobs show as separate jobs.
- A reusable workflow's jobs show as jobs of the calling run.
- Runs from before the App was installed are not imported. Security alerts are, through the 6-hourly sync.