About GitHub Actions

GitHub Actions enables you to create custom software development life cycle (SDLC) workflows directly in your GitHub repository.

GitHub Actions is currently in limited public beta and is subject to change. We strongly recommend that you do not use this feature for high-value workflows and content during the beta period.

For more information about using GitHub Actions, see "Automating your workflow with GitHub Actions."

In this article

About GitHub Actions

GitHub Actions gives you the flexibility to build an automated software development lifecycle workflow. You can write individual tasks, called actions, and combine them to create a custom workflow. Workflows are custom automated processes that you can set up in your repository to build, test, package, release, or deploy any code project on GitHub.

With GitHub Actions you can build end-to-end continuous integration (CI) and continuous deployment (CD) capabilities directly in your repository. GitHub Actions powers GitHub's built-in continuous integration service. For more information, see "About continuous integration."

Workflows run in Linux, macOS, Windows, and containers on GitHub-hosted servers. You can create workflows using actions defined in your repository, open source actions in a public repository on GitHub, or a published Docker container image. Workflows in forked repositories don't run by default.

You can discover actions to use in your workflow on GitHub and build actions to share with the GitHub community. For more information on creating a custom action, see "Building actions."

You can create a workflow file configured to run on specific events. For more information, see "Configuring a workflow" and "Workflow syntax for GitHub Actions".

Core concepts for GitHub Actions

These are some common terms that have specific meaning when using GitHub Actions.


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.

Workflow run

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.

Workflow file

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 .github/workflows directory.


A defined task made up of steps. Each job is run in a fresh instance of the virtual environment. 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.


A step is a set of tasks performed by a job. Each step in a job executes in the same virtual environment, allowing the actions in that job to share information using the filesystem. Steps can run commands or actions.


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.

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.

Virtual environment

GitHub hosts Linux, macOS, and Windows virtual environments to run your workflows.


A GitHub service in each virtual environment that 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.


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.


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.

Notifications for workflow runs

If you enable email or web notifications for GitHub Actions, you'll receive a notification when any workflow runs that you've triggered have completed. The notification will include the workflow run's status (including successful, failed, neutral, and canceled runs). You can also choose to receive a notification only when a workflow run has failed.

You can also see the status of workflow runs on a repository's Actions tab. For more information, see "Managing a workflow run."

Discovering actions in the GitHub community

You can customize your project with open source actions shared in public repositories on GitHub. You can browse and use actions built by GitHub in the github.com/actions organization.

Migrating GitHub Actions from HCL to YAML syntax

GitHub no longer supports the HCL syntax in GitHub Actions.

If you participated in the limited public beta and created workflows with the HCL syntax, you will need to upgrade to the new limited public beta that uses YAML syntax. When your repository is eligible to upgrade, you'll see an invitation in your repository. You must accept the invitation before you can use the new limited public beta.

You'll need to migrate any workflow files that use HCL syntax to use the new YAML syntax. For more information about the YAML syntax and other changes to GitHub Actions, see "Workflow syntax for GitHub Actions" and "About GitHub Actions."

You'll also need to ensure you create a metadata file for any actions you've built. For more information, see "Metadata syntax for GitHub Actions" and "About actions."

Usage limits

Exceeding usage limits may result in jobs queueing, failing to run, or failing to complete. Limits are subject to change.

Additionally, GitHub Actions should not be used for:

In order to prevent violations of these limitations and abuse of GitHub Actions, GitHub may monitor your use of GitHub Actions. Misuse of GitHub Actions may result in termination of jobs, or restrictions in your ability to use GitHub Actions.

Requesting to join the limited public beta for GitHub Actions

GitHub Actions is currently in limited public beta and is subject to change. We strongly recommend that you do not use this feature for high-value workflows and content during the beta period.

If you're not currently participating in the limited public beta, you can request to join the limited public beta on the GitHub Actions page.

Contacting support

If you need help with anything related to workflow configuration, such as syntax, virtual environments, or building actions, look for an existing topic or start a new one in the GitHub Community Forum's GitHub Actions board.

If you have feedback or feature requests for GitHub Actions, share those in the Feedback form for GitHub Actions.

Contact GitHub Support or GitHub Premium Support for any of the following, whether your use or intended use falls into the usage limit categories:

If you're not currently participating in the limited public beta, you can request to join the limited public beta on the GitHub Actions page.

GitHub Support will only provide support for the YAML syntax and no longer provides support for the HCL syntax.

Further reading

Ask a human

Can't find what you're looking for?

Contact us