A pipeline turns a code change into a repeatable build and delivery process. In GitHub Actions, YAML workflow files live with the source code. A push triggers a run: GitHub provisions a runner, checks out the repository, executes the defined steps, then removes the runner. Each workflow can define jobs and the steps they run. section 16.1
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 small workflow runs a build job on Ubuntu. Its steps check out the code and run a PowerShell build script from the cicd directory. section 16.1
Keep the workflow YAML thin. Put most build logic in scripts so developers can run it locally and debug failures without a cloud runner. Dockerfiles can compile code and run unit tests; scripts can coordinate Docker and Compose commands and pass build details, such as the build number, into environment variables. section 16.1 section 16.5
A delivery pipeline can advance through distinct stages:
- Build and test the code, then build component images and push them to a staging repository. section 16.1 section 16.2
- Run end-to-end tests against the staging images. Push images that pass to a release repository for production deployment. section 16.2
- Test deployment from release images on a temporary Kubernetes cluster. Compose-based checks are quicker and lighter, but do not validate the Kubernetes deployment model. section 16.4
To check a workflow, commit and push its file, then inspect the run in GitHub Actions. Try a failing unit test to confirm the build fails; fix the test and push again. Separate workflows make stages easier to run independently. A single workflow instead makes job dependencies and their graph easier to see. section 16.1 section 16.5
