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
Intro
GitHub Actions
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform built into GitHub. It lets you automate build, test, and deployment pipelines directly from the repository that holds your code: you can build and test every pull request, or deploy merged changes to production. It also goes beyond CI/CD — a workflow can react to almost anything that happens in a repository, such as automatically labeling a newly opened issue.
The key structural difference from a standalone automation server is that there is no server. GitHub hosts the scheduling, the user interface, the logs, and — unless you opt out — the machines your automation runs on. You bring YAML files and, where needed, your own runners; GitHub operates the rest.
The mental model
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
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