What should run when someone proposes a change?
Keep a workflow file with the app in .github/workflows. Tell GitHub to start it for the proposed change, then run the same check the app already uses. The runner is the computer that executes the job.
Start with one check that can catch a real mistake, such as an appointment form accepting a time that is already reserved. Keep the publishing job separate and make it depend on a passing check.
When can a release wait for approval?
A deployment job can target an environment, a named destination like staging or production. Confirm that the destination and protection rules exist before relying on them.
GitHub Free cannot configure environments for a private repository. GitHub Pro, Team and Enterprise support private environments, but on Pro and Team, required reviewers are only available for public repositories. Check your plan before promising a reviewer gate for a private app.
Which runs cost money and what should you keep?
Standard GitHub-hosted runners are free for public repositories. For private repositories, check included usage and the rate for the machine you choose. Track workflow artifact storage separately.
A workflow artifact is a file a run saves, such as its test report. Download reports you need to retain and check retention before relying on run history. Keep the workflow file with the code and record any settings and permissions that live outside it.
How can you spot a missing check on paper?
Draw a proposed change, a check result and a publish decision for your own fictional app. Use no connected repository or account.
- Make the check failWrite “the second booking of the same time was accepted.” Draw the workflow stopping before any publish job.
- Make the check passWrite “the duplicate was rejected.” Record the proposed change you would approve for a test release.