GitHub Actions is the automation and CI/CD system built directly into GitHub. In an August 8, 2019 post on the GitHub blog, the company announced that Actions now supported continuous integration and continuous delivery, describing it as a way to “automate how you build, test, and deploy your projects on any platform, including Linux, macOS, and Windows.” It was offered free for public repositories, with pay-as-you-go pricing for private ones, and reached general availability later that year.
Workflows are defined as code. The launch introduced “a clean new syntax for expressing workflows based on YAML,” stored as files inside a repository’s .github/workflows directory. Each workflow listens for events such as a push or a pull request and runs one or more jobs made up of individual steps. The documentation frames Actions as a way to run these workflows automatically whenever activity happens in the repository, keeping the automation versioned alongside the code it builds.
A defining feature is the marketplace of reusable actions. Rather than scripting every step by hand, a workflow can reference a published action, a packaged unit of automation contributed by GitHub or the community, and compose those building blocks into a pipeline. The original announcement also highlighted matrix builds for testing multiple versions of a project in parallel, live log streaming, and multi-container testing via Docker.
Jobs execute on runners, which are the machines that carry out the work. GitHub provides hosted runners across Linux, macOS, and Windows, and teams can register their own self-hosted runners to run jobs on their own infrastructure. This model placed a full CI/CD engine inside the same platform that already hosted the repository, pull requests, and issues.
By integrating automation so tightly with the repository, GitHub Actions lowered the barrier to adopting pipeline-as-code for the large population of projects already hosted on GitHub. It became a direct competitor to standalone services and helped normalize the expectation that build, test, and deploy logic should live in the repository itself rather than in a separate, externally configured system.