GitHub Actions
GitHub Actions is a CI/CD platform built into GitHub that automates workflows triggered by repository events. You define jobs in YAML files, compose reusable actions, and run builds, tests, and deployments on GitHub-hosted or self-hosted runners.
itDevOps and software delivery | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Do Not Panic: GitHub Actions
GitHub Actions is automation that lives in the same repository as the code it acts on. A YAML file watches for something happening, then asks a runner to do work. That is the whole machine. It is a small machine with access to builds, tests, releases, and occasionally the keys to a kingdom, which is why it deserves more attention than a decorative configuration file.
Before Actions, a team commonly maintained a separate automation server or wired one to its source control system. Actions puts the event, workflow, logs, and usually the runner in one place. A workflow is the YAML file in the dot-github slash workflows directory. An event starts it. A job gets a runner. Its steps share that runner and run in order, which is convenient until someone assumes a different job can see the same files. It cannot. Computers remain strict about this.
The useful surprise is that a workflow is not only CI. A push can start one, but so can a pull request, an issue, a schedule, or a manual request. That makes Actions useful for repository housekeeping as well as build and deployment work. It also means the event is part of the security design. A pull request from outside the trust boundary is not the same creature as a commit on the protected branch, even if both arrive wearing YAML.
The second idea is runner choice. GitHub-hosted runners arrive as fresh virtual machines, run a job, then leave without demanding that you patch or scale them. A self-hosted runner can reach special hardware or a private network, but then it is your machine and your isolation problem again. Managed convenience has a boundary. It does not abolish one.
The third is GITHUB_TOKEN, the automatic token each job receives. Keep its permissions small. Every action is code from somewhere, and every secret or write permission makes that code more consequential. A green check says the steps ran. It does not certify the trigger, action reference, token scope, or checkout choice.
Read the intro for the component model and where Actions fits. Use the slides to see the event-to-runner path at a glance. Keep the cheatsheet nearby while reading workflow YAML, especially its failure table and security questions. Then try the practice reference and exercise in a disposable repository. The point is not to make YAML heroic. It is to make the authority behind it visible.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://github.com/features/actions
Supports
- Product homepage and catalog primary source
- https://docs.github.com/en/actions
Supports
- Overall documentation structure and learning-path framing
- Existence and naming of platform features - dependency caching, workflow artifacts, deployment environments, reusable workflows, runner groups, OIDC
- https://docs.github.com/en/actions/get-started/understand-github-actions
Supports
- GitHub Actions as a CI/CD platform automating build, test, and deployment
- Workflows triggered by repository events beyond CI/CD (e.g. labeling new issues)
- Components model - workflow, event, job, step, action, runner
- Workflows as YAML files in .github/workflows; multiple workflows per repository; manual and scheduled triggers
- Jobs run in parallel by default; dependencies serialize; matrix runs job variations
- Each runner runs a single job at a time; Ubuntu/Windows/macOS hosted runners; fresh VM per workflow run
- Actions as reusable task units; GitHub Marketplace; self-written actions
- https://docs.github.com/en/actions/get-started/quickstart
Supports
- Workflow files must live in .github/workflows with .yml or .yaml extension
- First-workflow journey - commit file, push event triggers run, view logs per step in Actions tab
- runs-on ubuntu-latest and run steps in example workflow
- actions/checkout@v6 as the current checkout action reference in official docs
- https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
Supports
- Workflow file keys - name, on (with branch filters), jobs, runs-on, steps, uses, run, with, env, needs, if, strategy.matrix, permissions, concurrency, environment
- Workflow files require .yml or .yaml extension in .github/workflows
- https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency
Supports
- Concurrency groups with group and cancel-in-progress, including the ci-${{ github.ref }} pattern
- One running job/workflow per concurrency group; queued runs pending or canceled
- https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
Supports
- Catalog of triggering events including push, pull_request, schedule, workflow_dispatch
- https://docs.github.com/en/actions/concepts/runners/github-hosted-runners
Supports
- GitHub-hosted runner characteristics and constraints
- https://docs.github.com/en/actions/concepts/runners/self-hosted-runners
Supports
- Self-hosted runners on own infrastructure for custom hardware, OS, or network needs
- https://docs.github.com/en/actions/concepts/security/secrets
Supports
- Secrets stored at organization, repository, or environment level
- Client-side encryption with Libsodium sealed boxes
- Workflows read a secret only when it is explicitly included
- Automatic redaction of secrets in logs is not guaranteed
- Environment secrets can require reviewer approval
- https://docs.github.com/en/actions/concepts/security/github_token
Supports
- Unique GITHUB_TOKEN automatically created per workflow job; expires when the job finishes
- Token permissions limited to the repository containing the workflow; configurable
- Maximum job execution time - 6 hours on GitHub-hosted runners, 5 days on self-hosted runners
- Events triggered by GITHUB_TOKEN do not create new workflow runs, with exceptions (workflow_dispatch, repository_dispatch, approval-gated pull_request runs)
- https://docs.github.com/en/actions/reference/security/secure-use
Supports
- Write access to a repository implies read access to all its secrets
- Set GITHUB_TOKEN default permissions to read-only; raise per job
- Never store sensitive data as plaintext in workflow files; structured data defeats redaction; delete logs and rotate exposed secrets
- Script-injection mitigations - use actions or intermediate environment variables for untrusted input
- pull_request_target and workflow_run are privileged triggers; combining them with untrusted checkout can lead to repository takeover
- Compromised third-party action can access workflow secrets and use GITHUB_TOKEN to write to the repository
- Pinning to a full-length commit SHA is currently the only way to use an action as an immutable release; tag pinning requires trusting the creator
- CODEOWNERS on .github/workflows for reviewed pipeline changes
- OpenID Connect recommended for short-lived, well-scoped cloud credentials
- GitHub-hosted runners run in ephemeral, clean, isolated VMs; self-hosted runners have no such guarantee, can be persistently compromised, and should almost never be used for public repositories
- Dependabot version and security updates for actions
- https://docs.github.com/en/actions/concepts/billing-and-usage
Supports
- Free for standard GitHub-hosted runners in public repositories and for self-hosted runners
- Private repositories receive a plan-dependent quota of free minutes and storage; beyond it usage is billed
- Minute multipliers applied to billed usage
- Reusable workflow billing is associated with the caller workflow
- Usage limits apply when using GitHub-hosted runners
- https://github.blog/changelog/2018-10-16-github-actions-limited-public-beta/
Supports
- Enrichment research citation
- https://github.blog/changelog/2019-08-08-updates-to-github-actions-limited-public-beta/
Supports
- Enrichment research citation
- https://github.blog/changelog/2019-11-11-github-actions-is-now-generally-available/
Supports
- Enrichment research citation
- https://github.blog/changelog/2020-12-08-github-actions-environments-environment-protection-rules-and-environment-secrets/
Supports
- Enrichment research citation
- https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
Supports
- Enrichment research citation
- https://github.blog/changelog/2021-09-20-github-actions-ephemeral-self-hosted-runners-new-webhooks-for-auto-scaling/
Supports
- Enrichment research citation
- https://github.blog/changelog/2021-11-24-github-actions-reusable-workflows-are-generally-available/
Supports
- Enrichment research citation
- https://github.blog/changelog/2023-12-14-github-actions-artifacts-v4-is-now-generally-available/
Supports
- Enrichment research citation
- https://about.gitlab.com/solutions/continuous-integration/
Supports
- Enrichment research citation
- https://circleci.com/
Supports
- Enrichment research citation
- https://www.jenkins.io/
Supports
- Enrichment research citation
- https://buildkite.com/
Supports
- Enrichment research citation
- https://azure.microsoft.com/products/devops/pipelines/
Supports
- Enrichment research citation
- https://securitylab.github.com/resources/github-actions-new-patterns-and-mitigations/
Supports
- Enrichment research citation
