Set up GitHub Actions CI/CD safely

1. Inventory the repository

Find each application’s manifest, lockfile, runtime version and scripts. Identify whether dependencies are installed at the repository root or inside an application. Confirm build, test, lint and typecheck commands from the project itself; do not add commands merely because a generic template includes them.

2. Make dependency installation reproducible

Commit the lockfile and use the package manager’s immutable install mode. Pin the runtime and package-manager version. For pnpm and Yarn, an exact packageManager declaration makes the intended version explicit. If the lockfile is out of date, fix it in the pull request rather than silently regenerating it in CI.

3. Keep pull request checks separate from production

Run validation on pull requests. Limit deployment to pushes on the full default-branch reference, not a short name that could also match a tag. Add timeouts and suitable concurrency controls. Put production credentials in the intended protected environment and give each job only the permissions it needs.

GitHub’s secure use reference explains immutable action SHA pinning and credential handling. Its environment documentation details protection rules and GitHub plan limitations.

4. Confirm what will deploy

Check the destination, application directory, required secrets and deployment command. Review the workflow diff before merging. A successful CI job, an approved deployment gate and a successful deployment are different results: inspect each one independently.

5. Maintain the workflow deliberately

Review action, runtime and CLI updates as changes to production infrastructure. Keep provenance for generated files so maintenance does not overwrite your edits. A changed documentation page is a review signal, not permission to rewrite a workflow automatically.