Concurrency limits can save you money

• Avoid multiple commits in the same branch/PR from running at the same time

• Add this at workflow level, before jobs, in every workflow

# cancel any previously-started, yet still active runs of this workflow on the same branch
concurrency:
  group: ${{ github.ref }}-${{ github.workflow }}
  cancel-in-progress: true

You can do this in the extra credit slides later

Workflow design and parallelization

• Generally, one workflow per purpose (build and test image, lint code, deploy)
• Jobs are isolated from each other on different runners
• Jobs run in parallel by default, but:
• Jobs can depend on each other to control order
• Workflows can depend on another one finishing, or call another workflow directly
• It’s OK to only have one job per workflow
• ProTip: Creating a Matrix can simplify parallel testing (split up testing, or test on multiple OSes)
• If your job has dependency services, use service containers or Docker Compose
• Service containers are simpler. Docker Compose means you can easily reuse locally
• Over time, optimize for speed (parallelization) and cost (less minutes). It’s a balance
• Reusable workflows (Wednesday!) will greatly affect your workflow design

Ways to run a Workflow

• Normally a GitHub API event triggers a workflow (push, pull_request, issues)
• You can also run a workflow manually from the Actions tab, CLI, VS Code plugin, or webhook
• Workflows can start by depending on another one finishing

Keep YAML D.R.Y.

• You can have a Job call a "Reusable" Workflow in another repo (learn this Wednesday)
• You can make your own Actions and call them from a Job step in another repo
• You can make your own "Starter" Workflow templates in your Orgs .github repo (not as D.R.Y.)