**GitHub Actions** is the CI/CD and automation feature of 📝GitHub that runs workflows defined as YAML files in a repository's .github/workflows directory, triggered by repository events, cron schedules, or manual dispatch. It exists because build, test, and release automation previously required a separate service wired to the repository by webhook, with its own credentials and permission model; Actions collapses that into the same place the code and pull requests already live. It serves any team hosting on GitHub, from single-maintainer projects on the free tier to enterprises running self-hosted runner fleets.
Key Capabilities
- Event-driven workflows — Jobs trigger on pushes, pull requests, cron schedules, or manual dispatch, with concurrency groups that cancel superseded runs.
- Hosted and self-hosted runners — GitHub-hosted Linux, Windows, macOS, and ARM images, or your own machines managed through Actions Runner Controller.
- Service containers — Jobs can start dependencies like Postgres or MongoDB as Docker services with health checks, so tests run against real backing stores.
- Environments and scoped secrets — Deployment environments gate jobs behind approval rules and scope secrets to a named environment rather than the whole repository.
- Reusable marketplace actions — Steps call published actions by tag or pinned commit SHA, covering checkout, language setup, caching, and third-party integrations.
Getting Started
- Create a
.github/workflows/ci.ymlfile in your repository. - Set
on:to the triggering events — push, pull_request, schedule, workflow_dispatch. - Choose a runner with
runs-on: ubuntu-latestand list build steps understeps:. - Store credentials as repository or environment secrets, never inline in the YAML.
- Push the branch, then watch the run under the repository's Actions tab.
Related
- 📝GitHub Alternatives — what replacing Actions would actually cost