Acerca de los flujos de trabajo
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.
Conceptos básicos del flujo de trabajo
Un flujo de trabajo debe contener los siguientes componentes básicos:
- Uno o varios eventos que desencadenarán el flujo de trabajo.
- Uno o varios trabajos, cada uno de los cuales se ejecutará en una máquina del ejecutor y ejecutará uno o varios pasos.
- Cada paso puede ejecutar un script que definas, o bien una acción, que es una extensión reutilizable que puede simplificar el flujo de trabajo.
Para obtener más información sobre estos componentes básicos, consulta "Entender las GitHub Actions".
Activar un flujo de trabajo
Los activadores de los flujos de trabajo son eventos que ocasionan que se ejecute un flujo de trabajo. Estos eventos pueden ser:
- Eventos que ocurren en el repositorio de tu flujo de trabajo
- Eventos que se producen fuera de GitHub Enterprise Server y desencadenan un evento
repository_dispatch
en GitHub Enterprise Server - Tiempos programados
- Manual
Por ejemplo, puedes configurar tu flujo de trabajo para que se ejecute cuando se realiza una subida a la rama predeterminada de tu repositorio, cuando se crea un lanzamiento o cuando se abre una propuesta.
Para más información, consulta "Activar un flujo de trabajo," y para ver la lista completa de eventos, consulta "Eventos que desencadenan flujos de trabajo".
Sintaxis de flujos de trabajo
Los flujos de trabajo se definen mediante YAML. Para obtener la referencia completa de la sintaxis de YAML para crear flujos de trabajo, consulta "Sintaxis del flujo de trabajo para Acciones de GitHub".
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: '20' - 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: '20' - 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 20.) This puts both the `node` and `npm` commands in your `PATH`. - uses: actions/setup-node@v4 with: node-version: '20' # 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: '20'
This step uses the actions/setup-node@v4
action to install the specified version of the Node.js. (This example uses version 20.) 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 20.) This puts both the `node` and `npm` commands in your `PATH`.
- uses: actions/setup-node@v4
with:
node-version: '20'
# 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.
Para obtener más información sobre cómo administrar ejecuciones de flujo de trabajo (por ejemplo, volver a ejecutar, cancelar o eliminar una ejecución de flujo de trabajo), consulta "Administrar ejecuciones de flujo de trabajo".
Utilizar flujos de trabajo iniciales
GitHub proporciona flujos de trabajo preconfigurados que puedes personalizar para crear tu propio flujo de trabajo de integración continua. GitHub Enterprise Server analiza tu código y te muestra flujos de trabajo inicial de CI que podrían ser útiles para tu repositorio. Por ejemplo, si tu repositorio contiene un código Node.js, verás sugerencias para los proyectos de Node.js. Puedes utilizar flujos de trabajo iniciales como un primer paso para crear un flujo de trabajo personalizado o utilizarlos tal cual.
Puedes examinar la lista completa del flujo de trabajo de inicio en el repositorio actions/starter-workflows
en tu instancia de GitHub Enterprise Server.
Para obtener más información sobre el uso y la creación de flujos de trabajo de inicio, consulta "Utilizar flujos de trabajo iniciales" y "Crear flujos de trabajo iniciales para tu organización".
Características avanzadas de los flujos de trabajo
En esta sección se describen brevemente algunas de las características avanzadas de las GitHub Actions que te ayudan a crear flujos de trabajo más complejos.
Almacenamiento de secretos
Si los flujos de trabajo usan datos confidenciales como contraseñas o certificados, puede guardarlos en GitHub como secretos y luego usarlos en los flujos de trabajo como variables de entorno. Esto significa que podrás crear y compartir flujos de trabajo sin tener que insertar valores confidenciales directamente en el origen de YAML del flujo de trabajo.
Este trabajo de ejemplo muestra cómo hacer referencia a un secreto existente como una variable de entorno y enviarla como parámetro a un comando de ejemplo.
jobs:
example-job:
runs-on: ubuntu-latest
steps:
- name: Retrieve secret
env:
super_secret: ${{ secrets.SUPERSECRET }}
run: |
example-command "$super_secret"
Para obtener más información, vea «Uso de secretos en Acciones de GitHub».
Crear jobs dependientes
Predeterminadamente, los jobs en tu flujo de trabajo se ejecutan todos en paralelo y al mismo tiempo. Si tienes un trabajo que solo se debe ejecutar después de que se complete otro, puedes usar la palabra clave needs
para crear esta dependencia. Si se produce un error en uno de los trabajos, se omiten todos los trabajos dependientes; pero si necesitas que los trabajos continúen, puedes definir esto mediante la instrucción condicional if
.
En este ejemplo, los trabajos setup
, build
y test
ejecutan en serie, y build
y test
dependen de la finalización correcta del trabajo que los precede:
jobs:
setup:
runs-on: ubuntu-latest
steps:
- run: ./setup_server.sh
build:
needs: setup
runs-on: ubuntu-latest
steps:
- run: ./build_server.sh
test:
needs: build
runs-on: ubuntu-latest
steps:
- run: ./test_server.sh
Para obtener más información, vea «Utilizar jobs en un flujo de trabajo».
Uso de una matriz
Una estrategia de matriz permite usar variables en una definición de trabajo para crear automáticamente varias ejecuciones de trabajos basadas en las combinaciones de las variables. Por ejemplo, puedes usar una estrategia de matriz para probar el código en varias versiones de un lenguaje o en varios sistemas operativos. La matriz se crea mediante la palabra clave strategy
, que recibe las opciones de compilación como una matriz. Por ejemplo, esta matriz ejecutará el trabajo varias veces mediante el uso de versiones diferentes de Node.js:
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node: [14, 16]
steps:
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node }}
Para obtener más información, vea «Uso de una matriz para tus trabajos».
Almacenar dependencias en caché
Si los trabajos reutilizan regularmente las dependencias, puedes considerar la posibilidad de almacenar en caché estos archivos para ayudar a mejorar el rendimiento. Una vez que se crea el caché, estará disponible para todos los flujos de trabajo en el mismo repositorio.
Este ejemplo se ilustra cómo almacenar el directorio ~/.npm
en caché:
jobs:
example-job:
steps:
- name: Cache node modules
uses: actions/cache@v3
env:
cache-name: cache-node-modules
with:
path: ~/.npm
key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-build-${{ env.cache-name }}-
Para obtener más información, vea «Almacenar en caché las dependencias para agilizar los flujos de trabajo».
Usar bases de datos y contenedores de servicio
Si el trabajo necesita una base de datos o un servicio de caché, puede usar la palabra clave services
a fin de crear un contenedor efímero para hospedar el servicio; el contenedor resultante estará disponible para todos los pasos de ese trabajo y se quitará cuando se haya completado el trabajo. En este ejemplo se muestra cómo un trabajo puede usar services
para crear un contenedor postgres
y, después, usar node
para conectarse al servicio.
jobs:
container-job:
runs-on: ubuntu-latest
container: node:10.18-jessie
services:
postgres:
image: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v4
- name: Install dependencies
run: npm ci
- name: Connect to PostgreSQL
run: node client.js
env:
POSTGRES_HOST: postgres
POSTGRES_PORT: 5432
Para obtener más información, vea «Utilizar servicios de contenedor».
Utilizar etiquetas para enrutar los flujos de trabajo
Si quieres asegurarte de que un tipo específico de ejecutor procesará tu job, puedes utilizar etiquetas para controlar donde se ejecutan los jobs. Puede asignar etiquetas a un ejecutor autohospedado además de su etiqueta self-hosted
predeterminada. A continuación, puedes hacer referencia a estas etiquetas en el flujo de trabajo de YAML, asegurándote de que el trabajo se enruta de forma predecible. Los ejecutores hospedados en GitHub tienen asignadas etiquetas predefinidas.
Este ejemplo muestra como un flujo de trabajo puede utilizar etiquetas para especificar el ejecutor requerido:
jobs:
example-job:
runs-on: [self-hosted, linux, x64, gpu]
Un flujo de trabajo solo se ejecutará en un ejecutor que tenga todas las etiquetas en la runs-on
. El job irá preferencialmente a un ejecutor auto-hospedado inactivo con las etiquetas especificadas.
Para obtener más información sobre las etiquetas autoejecutables, consulta "Uso de etiquetas con ejecutores autohospedados".
Reutilización de flujos de trabajo
Puedes compartir flujos de trabajo con tu organización, privada o públicamente, si llamas a un flujo de trabajo desde dentro de otro. Esto te permite reutilizar flujos de trabajo, evitando la duplicación y haciendo que tus flujos se puedan mantener mejor. Para obtener más información, vea «Reutilización de flujos de trabajo».
Endurecimiento de seguridad para flujos de trabajo
GitHub proporciona características de seguridad que puede usar para aumentar la seguridad de los flujos de trabajo. Puede usar las características integradas de GitHub para asegurarse de que se le notifican las vulnerabilidades en las acciones que consume o para automatizar el proceso de mantener actualizadas las acciones de los flujos de trabajo. Para obtener más información, vea «Uso de las características de seguridad de GitHub para proteger el uso de Acciones de GitHub».
Utilizar ambientes
Puedes configurar entornos con reglas de protección y secretos para controlar la ejecución de trabajos en un flujo de trabajo. Cad job en un flujo de trabajo puede referenciar un solo ambiente. Cualquier regla de protección que se configure para el ambiente debe pasar antes de que un job que referencia al ambiente se envíe a un ejecutor. Para obtener más información, vea «Utilizar ambientes para el despliegue».