DevOps

GitHub Actions

GitHub Actions is CI/CD built into GitHub: YAML workflows run on repository events such as push or pull request.

What it is

GitHub Actions was announced in 2018 and became generally available in 2019. It is GitHub's CI/CD service: you put YAML files in .github/workflows and GitHub runs them on events (push, pull request, schedule, manual dispatch).

A workflow consists of jobs, each job runs on a runner (GitHub-hosted on Linux, Windows, macOS, or your self-hosted one) and contains steps. Steps either run commands or call ready-made actions from the Marketplace, such as checkout or setup-node.

It has build matrices, dependency caching, artifacts, secrets and environments with manual approval. Minutes are free for public repositories, private ones have a plan quota.

Use it when

  • Your code is already on GitHub and you want CI without a separate service.
  • You need to run tests, linters and builds on every pull request.
  • You automate deploys, releases and package publishing.
  • You need a build matrix across versions or OSes.

Avoid it when

  • Your code is not on GitHub: GitLab CI or Jenkins are more natural then.
  • You need full control of CI infrastructure with no dependence on a service (self-hosted runners or Jenkins can fit).

Key concepts

Workflow
A YAML file in .github/workflows that describes when and what to run.
Job / step
A job is a set of steps on one runner, jobs run in parallel by default.
Runner
The machine that runs a job: GitHub-hosted or your own self-hosted one.
Action
A reusable step called through uses.
Secrets / environments
Encrypted variables and environments with access rules and approvals.

Example

CI on pull requests and pushes to main: checkout, install dependencies and tests.

Cheat sheet

GitHub Actions cheat sheet
Command or codeWhat it does
on: [push, pull_request]When the workflow runs
runs-on: ubuntu-latestWhich runner the job uses
- uses: actions/checkout@v4Check out the repository code
- uses: actions/setup-node@v4Install the Node.js version you need
- run: pnpm install --frozen-lockfileRun a shell command
strategy: { matrix: { node: [20, 22] } }Matrix: the same job for several versions
env: { TOKEN: ${{ secrets.TOKEN }} }Pass a secret as an environment variable
needs: buildRun a job after another job
if: github.ref == 'refs/heads/main'Condition for a step or a job
- uses: actions/cache@v4Cache dependencies between runs
- uses: actions/upload-artifact@v4Save build files as an artifact

How to learn it

  1. Create a repo and a first workflow in .github/workflows/ci.yml that prints echo on every push.
  2. Take the GitHub Actions CI and CD course on ShortLesson to see the full cycle from commit to deploy.
  3. Learn the structure: on, jobs, runs-on, steps, uses versus run, and version matrices.
  4. Set up CI for your project: install dependencies, lint, tests and build on pull requests.
  5. Add dependency caching and artifacts to speed up the pipeline.
  6. Work with secrets and environment variables (secrets.*, vars.*) and never print them in logs.
  7. Deploy on push to main with a separate environment and manual approval for production.
  8. Extract repeated parts into reusable workflows or composite actions and try writing your own action.

Interview questions

  1. 1. What is the structure of a workflow?

    A workflow has triggers (on), one or more jobs, and each job has a runner and steps. Steps either run a command via run or call an action via uses.

  2. 2. How do you pass secrets safely?

    Store them in repository or environment Secrets and use them as ${{ secrets.NAME }}. For clouds prefer OIDC to avoid long-lived keys. Secrets are not exposed to forks.

  3. 3. How do you speed up a build?

    Cache dependencies (actions/cache or cache in setup-*), run jobs in parallel, use a matrix and cancel stale runs through concurrency.

Interview questions from the bank

Comparisons with this technology

Logos belong to their owners and are used for identification only. Icons: Simple Icons (CC0), Devicon (MIT).