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.)

Workshop 1 GHA further reading for the curious

(full GHA resources list on bretfisher.com)

1. Follow all the latest updates on GitHub Actions:
   1. https://github.blog/changelog/label/actions/
   2. https://github.blog/changelog/label/githubactions/
   3. https://twitter.com/GHchangelog (all changes)
   4. Follow the Roadmap Project. For example, here’s all dependabot feature releases
2. Docker Official Actions Docs
3. How do GitHub’s Public Runners work, and what’s installed on them?
4. List of “Awesome” Actions. Good for ideas on what to run: awesome-actions, (outdated but useful) and useful-actions, Official GitHub Actions, all Verified Actions