Why GitHub Actions

Strengths that defaulted the world to Actions

GitHub Actions launched in 2018 and became the default CI for most new projects within three years. The reasons are practical, not technical genius:

1. Lives next to the code. Workflows are YAML files in .github/workflows/. They version with the code, get reviewed in PRs, and are automatically scoped to the repo.
2. Marketplace. Tens of thousands of pre-built actions for common tasks: cache deps, deploy to AWS, build a Docker image, post to Slack. Composability is ridiculous.
3. Free for open source. Generous free minutes for public repos and free macOS / Windows runners. This is why every modern OSS project ships with a green build badge.
4. One auth. If you have a GitHub account, you have CI. No separate tool to provision, license, or bill.
5. Native UI integration. Status checks on PRs, environment deployments, secrets management — all in the same UI as code review.

Weaknesses worth knowing

• Vendor lock-in is real. Workflow YAML and the action ecosystem are GitHub-specific. Migrating off is non-trivial.
• Marketplace actions are mostly third-party code. Pin them by SHA, audit important ones, never use latest in production. (We'll cover this in the secrets/security tracks.)
• Slow for very heavy workloads. If you need 64-core machines or GPU runners with persistent caches, you usually self-host runners.
• Stateful workflows are awkward. Actions is great at stateless build/test/deploy. For long-running stateful pipelines (multi-day batch jobs), you'll want orchestrators like Argo or Airflow on top.