Core concepts for GitHub Actions
Below is a list of common GitHub Actions terms we use across our sites and GitHub Actions documentation.
GitHub Actions is available with GitHub Free, GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub One. GitHub Actions is not available for public or private repositories owned by accounts using legacy per-repository plans. For more information, see "GitHub's products."
In this article
- Continuous integration (CI)
- Continuous deployment (CD)
- GitHub-hosted runner
- Self-hosted runner
- Virtual environment
- Workflow file
- Workflow run
Individual tasks that you combine as steps to create a job. Actions are the smallest portable building block of a workflow. You can create your own actions, use actions shared from the GitHub community, and customize public actions. To use an action in a workflow, you must include it as a step.
Artifacts are the files created when you build and test your code. For example, artifacts might include binary or package files, test results, screenshots, or log files. Artifacts are associated with the workflow run where they were created and can be used by another job or deployed.
Continuous integration (CI)
The software development practice of frequently committing small code changes to a shared repository. With GitHub Actions, you can create custom CI workflows that automate building and testing your code. From your repository, you can view the status of your code changes and detailed logs for each action in your workflow. CI saves developers time by providing immediate feedback on code changes to detect and resolve bugs faster.
Continuous deployment (CD)
Continuous deployment builds on continuous integration. When new code is committed and passes your CI tests, the code is automatically deployed to production. With GitHub Actions, you can create custom CD workflows to automatically deploy your code to any cloud, self-hosted service, or platform from your repository. CD saves developers time by automating the deployment process and deploys tested, stable code changes more quickly to your customers.
A specific activity that triggers a workflow run. For example, activity can originate from GitHub when someone pushes a commit to a repository or when an issue or pull request is created. You can also configure a workflow to run when an external event occurs using the repository dispatch webhook.
GitHub hosts Linux, Windows, and macOS runners. Jobs run in a fresh instance of a virtual machine that includes commonly-used, preinstalled software. GitHub performs all upgrades and maintenance of GitHub-hosted runners. You cannot customize the hardware configuration of GitHub-hosted runners. For more information, see "Virtual environments for GitHub-hosted runners."
A defined task made up of steps. You can define the dependency rules for how jobs run in a workflow file. Jobs can run at the same time in parallel or be dependent on the status of a previous job and run sequentially. For example, a workflow can have two sequential jobs that build and test code, where the test job is dependent on the status of the build job. If the build job fails, the test job will not run. For GitHub-hosted runners, each job in a workflow runs in a fresh instance of a virtual environment.
Any machine with the GitHub Actions runner application installed. You can use a runner hosted by GitHub or host your own runner. A runner waits for available jobs. When a runner picks up a job, it runs the job's actions and reports the progress, logs, and final results back to GitHub. Runners run one job at a time. For more information, see "GitHub-hosted runner" and "Self-hosted runner."
Note: The GitHub Actions runner application is open source. You can contribute and file issues in the runner repository.
A machine you manage and maintain with the runner application installed. Self-hosted runners offer more control of hardware, operating system, and software tools than GitHub-hosted runners provide. With self-hosted runners, you can choose to create a custom hardware configuration with more processing power or memory to run larger jobs, install software available on your local network, and choose an operating system not offered by GitHub-hosted runners. For more information, see "Hosting your own runners."
A step is a set of tasks performed by a job. Each step in a job executes in the same runner, allowing the actions in that job to share information using the filesystem. Steps can run commands or actions.
The virtual environment of a GitHub-hosted runner includes the virtual machine's hardware configuration, operating system, and installed software. For more information, see "Virtual environments for GitHub-hosted runners."
A configurable automated process that you can set up in your repository to build, test, package, release, or deploy any project on GitHub. Workflows are made up of one or more jobs and can be scheduled or activated by an event.
The YAML file that defines your workflow configuration with at least one job. This file lives in the root of your GitHub repository in the
An instance of your workflow that runs when the pre-configured event occurs. You can see the jobs, actions, logs, and statuses for each workflow run.