Nota: Actualmente los ejecutores hospedados en GitHub no se admiten en GitHub Enterprise Server. Puede ver más información sobre la compatibilidad futura planeada en GitHub public roadmap.
Información general
GitHub Actions es una plataforma de integración y despliegue continuos (IC/DC) que te permite automatizar tu mapa de compilación, pruebas y despliegue. Puedes crear flujos de trabajo y crear y probar cada solicitud de cambios en tu repositorio o desplegar solicitudes de cambios fusionadas a producción.
GitHub Actions va más allá de solo DevOps y te permite ejecutar flujos de trabajo cuando otros eventos suceden en tu repositorio. Por ejemplo, puedes ejecutar un flujo de trabajo para que agregue automáticamente las etiquetas adecuadas cada que alguien cree una propuesta nueva en tu repositorio.
Debes hospedar tus propias máquinas virtuales Linux, Windows o macOS para ejecutar flujos de trabajo de tu instancia de GitHub Enterprise Server. Los ejecutores autohospedados pueden ser físicos, virtuales, en un contenedor, locales o en una nube.
Para obtener más información sobre la introducción de GitHub Actions en la empresa, consulta "Intruducir las GitHub Actions a tu empresa".
Los componentes de las GitHub Actions
Puede configurar un flujo de trabajo de GitHub Actions que se desencadene cuando se produzca un evento en el repositorio, por ejemplo, la apertura de una solicitud de incorporación de cambios o la creación de una incidencia. El flujo de trabajo contiene uno o varios trabajos que se pueden ejecutar en orden secuencial o en paralelo. Cada trabajo se ejecutará dentro de su propio ejecutor de máquina virtual o dentro de un contenedor, y tendrá uno o varios pasos que pueden ejecutar un script que defina, o bien una acción, que es una extensión reutilizable que puede simplificar el flujo de trabajo.
Workflows
Un flujo de trabajo es un proceso automatizado configurable que ejecutará uno o más jobs. Los flujos de trabajo se definen mediante un archivo de YAML que se verifica en tu repositorio y se ejecutará cuando lo active un evento dentro de este o puede activarse manualmente o en una programación definida.
Los flujos de trabajo se definen en el directorio .github/workflows
de un repositorio y un repositorio puede tener varios flujos de trabajo, cada uno de los cuales puede realizar un conjunto diferente de tareas. Por ejemplo, puedes tener un flujo de trabajo para crear y probar las solicitudes de cambio, otro para desplegar tu aplicación cada que se cree un lanzamiento y todavía otro más que agregue una etiqueta cada que alguien abra una propuesta nueva.
Puede hacer referencia a un flujo de trabajo dentro de otro flujo de trabajo. Para obtener más información, vea «Reutilización de flujos de trabajo».
Para obtener más información sobre los flujos de trabajo, consulte "Uso de flujos de trabajo."
Eventos
Un evento es una actividad específica en un repositorio, la cual activa una ejecución de flujo de trabajo. Por ejemplo, la actividad puede originarse desde GitHub cuando alguien crea una solicitud de cambios, abre una propuesta o sube una confirmación a un repositorio. También puede desencadenar una ejecución de flujo de trabajo según una programación, mediante la publicación en una API de REST o manualmente.
Para obtener una lista completa de eventos que se pueden usar para desencadenar flujos de trabajo, vea Eventos que desencadenan flujos de trabajo.
Trabajos
Un trabajo es un conjunto de pasos de un flujo de trabajo que se ejecuta en el mismo ejecutor. Cada paso puede ser un script de shell o una acción que se ejecutarán. Los pasos se ejecutarán en orden y serán dependientes uno del otro. Ya que cada paso se ejecuta en el mismo ejecutor, puedes compartir datos de un paso a otro. Por ejemplo, puedes tener un paso que compile tu aplicación, seguido de otro que pruebe la aplicación que se compiló.
Puedes configurar las dependencias de un job con otros jobs; predeterminadamente, los jobs no tienen dependencias y se ejecutan en paralelo entre ellos. Cuando un job lleva una dependencia a otro job, este esperará a que el job dependiente se complete antes de que pueda ejecutarse. Por ejemplo, puedes tener jobs de compilación múltiple para arquitecturas diferentes que no tengan dependencias y un job de empaquetado que sea dependiente de estos jobs. Los jobs de compilación se ejecutarán en paralelo y, cuando se hayan completado con éxito, se ejecutará el job de empaquetado.
Para obtener más información sobre los trabajos, consulte "Utilizar jobs".
Acciones
Una acción es una aplicación personalizada para la plataforma de GitHub Actions que realiza una tarea compleja pero que se repite frecuentemente. Utiliza una acción para ayudarte a reducir la cantidad de código repetitivo que escribes en tus archivos de flujo de trabajo. Una acción puede extraer tu repositorio de git desde GitHub, configurar la cadena de herramientas correcta para tu ambiente de compilación o configurar la autenticación en tu proveedor de servicios en la nube.
Puedes escribir tus propias acciones o puedes encontrar acciones para utilizar en tus flujos de trabajo dentro de GitHub Marketplace.
Para compartir las acciones en toda la empresa sin publicarlas de forma pública, puedes almacenarlas en un repositorio interno y luego configurarlo para que acceda a los flujos de trabajo de GitHub Actions en otros repositorios que sean propiedad de la misma organización o de una organización de la empresa. Para obtener más información, vea «Compartir acciones y flujos de trabajo con tu empresa».
Para obtener más información, vea «Crear acciones».
Ejecutores
Un ejecutor es un servidor que ejecuta tus flujos de trabajo cuando se activan. Cada ejecutor puede ejecutar un job individual a la vez. Debes hospedar tus propios ejecutores para GitHub Enterprise Server. Para más información, consulte "Alojar tus propios corredores".
Crear un flujo de trabajo de ejemplo
Las GitHub Actions utilizan la sintaxis de YAML para definir el flujo de trabajo. Cada flujo de trabajo se almacena como un archivo YAML independiente en el repositorio de código, en un directorio denominado .github/workflows
.
Puedes crear un flujo de trabajo de ejemplo en tu repositorio que active automáticamente una serie de comandos cada que se suba código. En este flujo de trabajo GitHub Actions extrae el código insertado, instala el marco de pruebas de bats y ejecuta un comando básico para generar la versión de los bats: bats -v
.
-
En el repositorio, cree el directorio
.github/workflows/
para almacenar los archivos de flujo de trabajo. -
En el directorio
.github/workflows/
, cree un archivo denominadolearn-github-actions.yml
y agregue el código siguiente.YAML name: learn-github-actions run-name: ${{ github.actor }} is learning GitHub Actions on: [push] jobs: check-bats-version: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '14' - run: npm install -g bats - run: bats -v
name: learn-github-actions run-name: ${{ github.actor }} is learning GitHub Actions on: [push] jobs: check-bats-version: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '14' - run: npm install -g bats - run: bats -v
-
Confirma estos cambios y cárgalos a tu repositorio de GitHub.
Tu archivo de flujo de trabajo de GitHub Actions nuevo estará ahora instalado en tu repositorio y se ejecutará automáticamente cada que alguien suba un cambio a éste. Para ver los detalles sobre el historial de ejecución de un flujo de trabajo, consulta «Visualización de la actividad de una ejecución de flujo de trabajo».
Entender el archivo de flujo de trabajo
Para ayudarte a entender cómo se utiliza la sintaxis de YAML para crear un flujo de trabajo, esta sección explica cada línea del ejemplo de la introducción:
# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead. name: learn-github-actions # Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)." run-name: ${{ github.actor }} is learning GitHub Actions # Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)." on: [push] # Groups together all the jobs that run in the `learn-github-actions` workflow. jobs: # Defines a job named `check-bats-version`. The child keys will define properties of the job. check-bats-version: # Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)" runs-on: ubuntu-latest # Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script. steps: # The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code. - uses: actions/checkout@v4 # This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`. - uses: actions/setup-node@v4 with: node-version: '14' # The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package. - run: npm install -g bats # Finally, you'll run the `bats` command with a parameter that outputs the software version. - run: bats -v
name: learn-github-actions
Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
run-name: ${{ github.actor }} is learning GitHub Actions
Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the github
context to display the username of the actor that triggered the workflow run. For more information, see "Sintaxis del flujo de trabajo para Acciones de GitHub."
on: [push]
Specifies the trigger for this workflow. This example uses the push
event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Sintaxis del flujo de trabajo para Acciones de GitHub."
jobs:
Groups together all the jobs that run in the learn-github-actions
workflow.
check-bats-version:
Defines a job named check-bats-version
. The child keys will define properties of the job.
runs-on: ubuntu-latest
Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "Sintaxis del flujo de trabajo para Acciones de GitHub"
steps:
Groups together all the steps that run in the check-bats-version
job. Each item nested under this section is a separate action or shell script.
- uses: actions/checkout@v4
The uses
keyword specifies that this step will run v4
of the actions/checkout
action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
- uses: actions/setup-node@v4
with:
node-version: '14'
This step uses the actions/setup-node@v4
action to install the specified version of the Node.js. (This example uses version 14.) This puts both the node
and npm
commands in your PATH
.
- run: npm install -g bats
The run
keyword tells the job to execute a command on the runner. In this case, you are using npm
to install the bats
software testing package.
- run: bats -v
Finally, you'll run the bats
command with a parameter that outputs the software version.
# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions
# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions
# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]
# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:
# Defines a job named `check-bats-version`. The child keys will define properties of the job.
check-bats-version:
# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
runs-on: ubuntu-latest
# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
steps:
# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
- uses: actions/checkout@v4
# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`.
- uses: actions/setup-node@v4
with:
node-version: '14'
# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
- run: npm install -g bats
# Finally, you'll run the `bats` command with a parameter that outputs the software version.
- run: bats -v
Visualizar el archivo de flujo de trabajo
En este diagrama, puedes ver el archivo de flujo de trabajo que acabas de crear, así como la forma en que los componentes de GitHub Actions se organizan en una jerarquía. Cada paso ejecuta una acción o script de shell simples. Los pasos 1 y 2 ejecutan acciones, mientras que los pasos 3 y 4 ejecutan scripts de shell. Para encontrar más acciones precompiladas para los flujos de trabajo, consulta "Encontrar y personalizar las acciones".
Visualización de la actividad de una ejecución de flujo de trabajo
Cuando se desencadena el flujo de trabajo, se crea una ejecución de flujo de trabajo que ejecuta el flujo de trabajo. Una vez que el flujo de trabajo haya comenzado a ejecutarse, puedes ver una gráfica de visualización del progreso de dicha ejecución, así como la actividad de cada paso, en GitHub.
-
En tu instancia de GitHub Enterprise Server, navega a la página principal del repositorio.
-
En el nombre del repositorio, haz clic en Acciones.
-
En la barra lateral izquierda, da clic en el flujo de trabajo que quieras ver.
-
En la lista de ejecuciones de flujo de trabajo, haz clic en el nombre de la ejecución para ver el resumen de la ejecución de flujo de trabajo.
-
En la barra lateral izquierda o en el gráfico de visualización, haz clic en el trabajo que quieres ver.
-
Para ver los resultados de un paso, haz clic en él.
Pasos siguientes
GitHub Actions puede ayudarte a automatizar casi cualquier aspecto de tu s procesos de desarrollo de aplicaciones. ¿Ya está listo para comenzar? Aquí tienes algunos recursos útiles para que tomes tus siguientes pasos con GitHub Actions:
- Para obtener una manera rápida de crear un flujo de trabajo de GitHub Actions, consulte “Utilizar flujos de trabajo iniciales”.
- Para conocer los flujos de trabajo de integración continua (CI) para compilar y probar el código, consulta "Compilaciones automáticas y pruebas".
- Para compilar y publicar paquetes, consulta "Publicar paquetes".
- Para implementar proyectos, consulta "Implementación".
- Para automatizar tareas y procesos en GitHub, consulta "Administrar propuestas y solicitudes de cambios".
- Para ejemplos que muestren características más complejas de GitHub Actions, incluidos muchos de los casos de uso anteriores, consulta "Ejemplos". Puede ver ejemplos detallados que explican cómo probar el código en un ejecutor, acceder a la CLI de GitHub y usar características avanzadas, como la simultaneidad y las matrices de prueba.