GitHub Actions

What is GitHub Actions?

GitHub Actions is the CI/CD and automation platform built directly into GitHub. You define workflows in YAML files in your repository (.github/workflows/), triggered by events — a push, a pull request, a release, a schedule, or manual dispatch — and GitHub runs them on hosted or self-hosted runners. Because it lives inside GitHub, it’s tightly integrated with the pull-request workflow, and its killer feature is the Marketplace: a huge library of reusable, pre-built actions (community and vendor-provided) you compose into workflows, so common tasks (checkout, setup a language, deploy to a cloud) are one line instead of custom scripting. For any project already on GitHub, it’s the natural, low-friction CI/CD choice, and it dominates open source.

How it works and why it spread so fast

The model is workflow-as-code triggered by git events: workflows are versioned with your code, reviewable, and reproducible, and they respond to the events that already structure your development (open a PR → run tests; merge to main → deploy). Workflows contain jobs (which run in parallel by default, each on a fresh runner) made of steps, where a step either runs shell commands or invokes a reusable action from the Marketplace. That composability is the reason GitHub Actions grew explosively — instead of writing integration glue, you pull a maintained action for it — combined with generous hosted runners (Linux, Windows, macOS provided by GitHub, free for public repos and with included minutes for private ones) that mean most teams need no CI infrastructure at all. It maps cleanly onto the general CI/CD idea: automatically build and test every change to catch problems early, then automate the path to deployment.

The tradeoffs and the security realities that bite

GitHub Actions is convenient but has real considerations. On positioning: it’s git-native and has the largest action marketplace and open-source mindshare, versus GitLab CI (deeply integrated in GitLab’s all-in-one platform, strong for self-hosted enterprise) and Jenkins (max flexibility, self-hosted, heavier). If you’re on GitHub, Actions is usually the path of least resistance. The security realities are the most important part and the most mishandled: third-party Marketplace actions run with access to your repository and secrets, so an unpinned or compromised action is a genuine supply-chain risk — the disciplines are pinning actions to a full commit SHA (not a mutable tag like @v3, which can be moved to malicious code), vetting third-party actions, and granting workflows least-privilege token permissions (the GITHUB_TOKEN and permissions: block). Secrets must live in GitHub Actions secrets, never hardcoded in YAML, and be scoped carefully. A notorious foot-gun is pull_request_target and workflows that run untrusted PR code with access to secrets — a well-known privilege-escalation vector that has leaked credentials in real incidents. Beyond security: self-hosted runners need hardening (they execute your CI with whatever access they have, and running untrusted code on them is dangerous), costs accrue on private-repo minutes and larger runners, and the usual CI hygiene applies (cache dependencies, parallelize, keep pipelines fast). The recurring mistakes: using unpinned third-party actions, over-permissioned tokens, secrets in plaintext, and unsafe handling of untrusted pull-request code.

What people get wrong

• Unpinned third-party actions — a Marketplace action runs with repo and secret access; pin to a full commit SHA and vet it, since a moved tag can point to malicious code.
• Over-permissioned workflows and exposed secrets: grant least-privilege token permissions and store secrets in GitHub Actions secrets — never hardcode them, and never expose them to untrusted PR code (pull_request_target foot-gun).
• Unhardened self-hosted runners — they execute CI with real access; running untrusted code on them, or leaving them over-permissioned, is a serious risk.

Primary source: GitHub Actions documentation