About continuous integration

You can create custom continuous integration (CI) and continuous deployment (CD) workflows directly in your GitHub repository with GitHub Actions.

GitHub Actions se encuentra disponible con GitHub Free, GitHub Pro, GitHub Free para organizaciones, GitHub Team, GitHub Enterprise Cloud, y GitHub One. GitHub Actions no se encuentra disponible para repositorios privados que pertenezcan a cuentas que utilicen planes tradicionales por repositorio. Para obtener más información, consulta la sección "Productos de GitHub".

En este artículo

About continuous integration

Continuous integration (CI) is a software practice that requires frequently committing code to a shared repository. Committing code more often detects errors sooner and reduces the amount of code a developer needs to debug when finding the source of an error. Frequent code updates also make it easier to merge changes from different members of a software development team. This is great for developers, who can spend more time writing code and less time debugging errors or resolving merge conflicts.

When you commit code to your repository, you can continuously build and test the code to make sure that the commit doesn't introduce errors. Your tests can include code linters (which check style formatting), security checks, code coverage, functional tests, and other custom checks.

Building and testing your code requires a server. You can build and test updates locally before pushing code to a repository, or you can use a CI server that checks for new code commits in a repository.

About continuous integration using GitHub Actions

CI using GitHub Actions offers workflows that can build the code in your repository and run your tests. Workflows can run on GitHub-hosted virtual machines, or on machines that you host yourself. For more information, see "Virtual environments for GitHub-hosted runners" and "About self-hosted runners."

You can configure your CI workflow to run when a GitHub event occurs (for example, when new code is pushed to your repository), on a set schedule, or when an external event occurs using the repository dispatch webhook.

GitHub runs your CI tests and provides the results of each test in the pull request, so you can see whether the change in your branch introduces an error. When all CI tests in a workflow pass, the changes you pushed are ready to be reviewed by a team member or merged. When a test fails, one of your changes may have caused the failure.

When you set up CI in your repository, GitHub analyzes the code in your repository and recommends CI workflows based on the language and framework in your repository. For example, if you use Node.js, GitHub will suggest a template file that installs your Node.js packages and runs your tests. You can use the CI workflow template suggested by GitHub, customize the suggested template, or create your own custom workflow file to run your CI tests.

Screenshot of suggested continuous integration templates

In addition to helping you set up CI workflows for your project, you can use GitHub Actions to create workflows across the full software development life cycle. For example, you can use actions to deploy, package, or release your project. For more information, see "About GitHub Actions."

For a definition of common terms, see "Core concepts for GitHub Actions."

Supported languages

GitHub offers CI workflow templates for a variety of languages and frameworks.

Browse the complete list of CI workflow templates offered by GitHub in the actions/starter-workflows repository.

Skipping workflow runs

If you want to temporarily prevent a workflow from being triggered, you can add a skip instruction to the commit message. Workflows that would otherwise be triggered on: push or on: pull_request, won't be triggered if you add any of the following strings to the commit message in a push, or the HEAD commit of a pull request:

  • [skip ci]
  • [ci skip]
  • [no ci]
  • [skip actions]
  • [actions skip]

Alternatively, you can end the commit message with two empty lines followed by either skip-checks: true or skip-checks:true.

You won't be able to merge the pull request if your repository is configured to require specific checks to pass first. To allow the pull request to be merged you can push a new commit to the pull request without the skip instruction in the commit message.

Note: Skip instructions only apply to the push and pull_request events. For example, adding [skip ci] to a commit message won't stop a workflow that's triggered on: pull_request_target from running.

Notifications for workflow runs

Si habilitas las notificaciones web o por correo electrónico para GitHub Actions, recibirás una notificación cuando alguna ejecución de flujo de trabajo que hayas activado se complete. La notificación incluirá el estado de la ejecución de flujo de trabajo (que incluye ejecuciones exitosas, fallidas, neutrales y canceladas). También puedes elegir recibir una notificación solo cuando falle una ejecución de flujo de trabajo.

También puedes ver el estado de las ejecuciones de flujo de trabajo en la pestaña Actions (Acciones) de un repositorio. Para obtener más información, consulta la sección "Administrar una ejecución de flujo de trabajo".

Status badges for workflow runs

A status badge shows whether a workflow is currently failing or passing. A common place to add a status badge is in the README.md file of your repository, but you can add it to any web page you'd like. By default, badges display the status of your default branch. You can also display the status of a workflow run for a specific branch or event using the branch and event query parameters in the URL.

example status badge

For more information, see "Adding a workflow status badge."

Further reading

Did this doc help you?Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

O, learn how to contribute.