Automate CI/CD with GitHub Actions Templates

GitHub Actions Templates supplies production-ready workflow patterns for testing, building and deploying applications, with an emphasis on security boundaries between untrusted validation and privileged publication. It is explicitly patterns, not an installed deployment program - repository policy, runner trust and environment settings must still be inspected, and every third-party action reviewed at its full commit SHA.

Its test workflow example is a Node.js job assuming npm test and Node 22, with actions pinned to explicit commit SHAs as review inputs to verify before adopting:

name: Test
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd
        with:
          persist-credentials: false
      - uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444
        with:
          node-version: '22'
          cache: npm
      - run: npm ci
      - run: npm test

For matrix builds, the guidance is to add a matrix only for the versions and operating systems the project actually supports, keep dependencies reproducible, identify failing combinations rather than hiding them with blanket continue-on-error, and test how required-check behavior holds up when jobs are conditionally skipped.

For build and publication, an artifact should be built from the tested commit with its identity recorded, and publication given a separate trusted job with the minimum registry permission - artifacts produced by arbitrary untrusted code must never be published from a privileged context, and accepted artifacts must be bound to their exact source and producing workflow.

For deployment, use the project's protected release path: identify the immutable artifact, destination, workload identity, and rollout/rollback checks before adding deployment commands. It specifically warns that a named GitHub environment does not configure reviewers automatically - its actual protections must be verified - and that a placeholder echo command must never be labeled a successful deployment.

Verification means exercising one passing change and one deliberate test failure on a topic branch, confirming the failing check blocks downstream publication, and inspecting tokens, runner isolation, caches and artifact boundaries, keeping production credentials out of untrusted validation jobs. The worked example: a project needing Linux and Windows tests should add both runner combinations, confirm either failure blocks the required result, and keep publication - with its registry credentials - entirely separate from the test matrix.

The bundled resources/implementation-playbook.md and references/common-workflows.md reinforce the same boundary: separate jobs for untrusted-source validation versus privileged publication, minimal validation-job permissions, reviewed immutable action revisions matched to commands that actually exist in the repository, artifacts bound to the tested commit, and a rejection of missing or mismatched provenance. Pull-request code must never run in a privileged, target-triggered job, and fork code must not be given production secrets, persistent runner access or a write token.

Use it to implement testing, matrix builds, artifact preparation, or an explicitly authorized deployment workflow for an existing repository. It is not a substitute for inspecting the actual repository's scripts, lockfile, supported runtimes, required check names and release policy first - these must be read before choosing job boundaries.

Inputs are the repository's existing workflow files, its scripts and lockfile, the supported runtime matrix, branch protection rules and deployment policy. Output is a verification report naming the actual files or configuration changed, the checks performed, the observed results, and any untested environment, with evidence sufficient to reproduce the conclusion.

It suits developers adding or hardening CI/CD workflows in a GitHub repository who need the untrusted-test versus privileged-publish boundary enforced correctly, not just a working YAML file.