Skip to content

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?