Integrations
GitHub Actions
PR gate pattern.
Overview
Design a GitHub Actions validation job with explicit permissions and reliable evidence handling.
Choose the triggering events, branches, runner environment, and commit under test. Evaluate forked pull requests separately because untrusted code and access to secrets must not share an unsafe execution boundary.
Who should read this
- Engineers and administrators assessing a GitHub Actions workflow.
Prerequisites
- An owner authorized to approve the target systems and data flows.
- Confirmation of the supported Zof integration method and service scope before creating a production dependency.
Step-by-step procedure
Define the integration boundary
Choose the triggering events, branches, runner environment, and commit under test. Evaluate forked pull requests separately because untrusted code and access to secrets must not share an unsafe execution boundary.
Review authority and data access
Set job permissions deliberately and use approved secret storage or workload identity where supported. Review third-party actions and pin dependencies according to your organization’s supply-chain policy.
Validate a representative workflow
Use a sample pull request to test success, a known failure, cancellation, and reruns. Confirm that any required check is produced for the intended commit and cannot report success merely because a job was skipped.
Investigate failures by category
Check event filters, runner network access, missing secrets in fork contexts, and job timeouts. Avoid changing to a more privileged event trigger simply to make secrets available to untrusted code.
Plan revocation and retirement
Remove unused workflow secrets and update branch protection when a check is renamed or retired. Retain the evidence needed to explain past release decisions.
Was this page helpful?