GitHub Actions

GitHub Actions is GitHub’s built-in automation and CI/CD platform. Workflows live in the repository and run in response to events, so build, test and deployment logic sits next to the code it serves.

How it works

A workflow is a YAML file in .github/workflows/. An event such as a push, a pull request, a schedule or a manual trigger starts it. A workflow contains one or more jobs, which run in parallel by default unless you declare dependencies. A job runs on a runner and is made of ordered steps, each either a shell command or an action, a reusable unit such as checking out the repository. A matrix lets one job run across several operating systems or language versions.

GitHub provides hosted runners for Ubuntu, Windows and macOS, and each run gets a fresh virtual machine. You can also use self-hosted runners when you need specific hardware or an operating system GitHub does not offer.

A practical example

name: ci
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps: [{uses: "actions/checkout@v4"}, {run: npm ci}, {run: npm test}]

The permissions block limits the automatic GITHUB_TOKEN to read-only access to repository contents, which is the least-privilege default GitHub recommends.

Common mistakes

• Using third-party actions by mutable tag. GitHub states that pinning to a full-length commit SHA is the only way to treat an action as immutable.
• Granting the token write access to every job instead of only the jobs that need it.
• Using pull_request_target while checking out untrusted fork code, which can expose secrets and write access.
• Storing structured data such as JSON as a single secret, which defeats log redaction.
• Relying on self-hosted runners for public repositories without isolating them.

When to use it and when not to

Actions is a natural fit when your code is already on GitHub, because it avoids a separate CI system, webhook set-up and cross-system access management. It is less suitable when your source lives elsewhere, or where a single pipeline tool must span several code hosts. Compare options in GitLab CI and Jenkins, or read our comparison of the three. Review any third-party action’s source before giving it access to secrets. For pipeline work, see CI/CD pipeline services.

See also

• CI/CD
• GitLab CI
• Jenkins
• GitHub Actions services