A build that works only on a developer’s machine gives the team unreliable feedback. GitHub Actions runs a CI/CD workflow when changes are pushed to a GitHub repository. A temporary runner checks out the code, executes the configured steps, and is cleaned up afterward. section 16.1
Define the workflow in YAML under `.github/workflows/`. Keep the GitHub-specific steps small: let the workflow check out the repository and call a script, while the script coordinates Docker builds and tests. You can then run the same script locally to debug a failure or adapt it for another CI/CD service. section 16.1 section 16.5
Listing 16.3 A simple GitHub workflow to run a PowerShell script
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
- name: build
working-directory: cicd
run: ./build.ps1
shell: pwsh
This build job uses an Ubuntu runner, checks out the repository, and runs `cicd/build.ps1` with PowerShell. The build logic stays outside the workflow YAML. section 16.1
Push a build and check the result
First run `./build.ps1` locally. Move `build.yaml` into `.github/workflows/`, then commit and push it; check the run in the repository’s Actions page. To test the failure path, enable the supplied failing test and rerun the build. After restoring the passing test, commit and push again to check that the next run succeeds. section 16.1
For a production pipeline, private repositories and packages need additional authentication configuration. Workflow design also involves a trade-off: one workflow can show job dependencies together in the UI, while separate stages are easier to run independently. A further practice task is to test a script that pushes Linux and Windows manifest lists to GHCR locally, then run it from a workflow. section 16.5 section 16.6
