Nota: GitHub Actions estuvo disponible para GitHub Enterprise Server 2.22 como un beta limitado. El beta terminó. GitHub Actions está ahora disponible habitualmente en GitHub Enterprise Server 3.0 o superior. Para obtener más información, consulta la sección de notas de lanzamiento para GitHub Enterprise Server 3.0.
- Para obtener más información acerca de cómo mejorar a GitHub Enterprise Server 3.0 o superior, consulta la sección "Mejorar a GitHub Enterprise Server".
- Para obtener más información acerca de configurar las GitHub Actions después de tu mejora, consulta la documentación de GitHub Enterprise Server 3.0.
Nota: Los ejecutores hospedados en GitHub no son compatibles con GitHub Enterprise Server actualmente. Puedes encontrar más información sobre el soporte que se tiene planeado en el futuro en el Itinerario público de GitHub.
Resumen
Este artículo describe algunas de las características avanzadas de las GitHub Actions que te ayudan a crear flujos de trabajo más complejos.
Almacenar secretos
Si tus flujos de trabajo utilizan datos sensibles tales como contraseñas o certificados, puedes guardarlos en GitHub como secretos y luego usarlos en tus flujos de trabajo como variables de ambiente. Esto significa que podrás crear y compartir flujos de trabajo sin tener que embeber valores sensibles directamente en el flujo de trabajo de YAML.
Esta acción de ejemplo ilustra cómo referenciar un secreto existente como una variable de ambiente 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, consulta "Crear y almacenar secretos cifrados".
Crear jobs dependientes
Predeterminadamente, los jobs en tu flujo de trabajo se ejecutan todos en paralelo y al mismo tiempo. Así que, si tienes un job que solo debe ejecutarse después de que se complete otro job, puedes utilizar la palabra clave needs
para crear esta dependencia. Si un de los jobs falla, todos los jobs dependientes se omitirán; sin embargo, si necesitas que los jobs sigan, puedes definir esto utilizando la declaración condicional if
.
En este ejemplo, los jobs de setup
, build
, y test
se ejecutan en serie, y build
y test
son dependientes de que el job que las precede se complete con éxito:
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, consulta la parte de jobs.<job_id>.needs
.
Utilizar una matriz de compilaciones
Puedes utilizar una matriz de compilaciones si quieres que tu flujo de trabajo ejecute pruebas a través de varias combinaciones de sistemas operativos, plataformas y lenguajes. La matriz de compilaciones se crea utilizando la palabra clave strategy
, la cual recibe las opciones de compilación como un arreglo. Por ejemplo, esta matriz de compilaciones ejecutará el job varias veces, utilizando diferentes versiones de Node.js:
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node: [6, 8, 10]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
Para obtener más información, consulta la parte de jobs.<job_id>.strategy.matrix
.
Usar bases de datos y contenedores de servicio
Si tu job requiere de un servicio de caché o de base de datos, puedes utilizar la palabra clave services
para crear un contenedor efímero para almacenar el servicio; el contenedor resultante estará entonces disponible para todos los pasos de ese job y se eliminará cuando el job se haya completado. Este ejemplo ilustra como un job puede utilizar services
para crear un contenedor de postgres
y luego utilizar a 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@v2
- 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, consulta la sección "Utilizar bases de datos y contenedores de servicios".
Utilizar etiquetas para enrutar los flujos de trabajo
Esta característica te ayuda a asignar jobs a un ejecutor hospedado específico. Si quieres asegurarte de que un tipo específico de ejecutor procesará tu job, puedes utilizar etiquetas para controlar donde se ejecutan los jobs. Puedes asignar etiquetas a un ejecutor auto-hospedado adicionalmente a su etiqueta predeterminada de self-hosted
. Entonces, puedes referirte a estas etiquetas en tu flujo de trabajo de YAML, garantizando que el job se enrute 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 el arreglo runs-on
. El job irá preferencialmente a un ejecutor auto-hospedado inactivo con las etiquetas especificadas. Si no hay alguno disponible y existe un ejecutor hospedado en GitHub con las etiquetas especificadas, el job irá a un ejecutor hospedado en GitHub.
Para aprender más acerca de las etiquetas auto-hospedadas, consulta la sección "Utilizar etiquetas con los ejecutores auto-hospedados". Para aprender más sobre las etiquetas de los ejecutores hospedados en GitHub, consulta la sección "Ejecutores compatibles y recursos de hardware".
Utilizar una plantilla de flujo de trabajo
GitHub proporciona plantillas de flujo de trabajo preconfiguradas que puedes personalizar para crear tu propio flujo de trabajo de integración contínua. GitHub Enterprise Server analiza tu código y muestra tus plantillas de IC 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 usar plantillas de flujo de trabajo como lugar de inicio para crear tu flujo de trabajo personalizado o usarlos tal como están.
Puedes buscar en la lista completa de plantillas de flujo de trabajo en el repositorio actions/starter-workflows
en tu instancia de GitHub Enterprise Server.
- En GitHub Enterprise Server, visita la página principal del repositorio.
- Debajo del nombre de tu repositorio, da clic en Acciones.
- Si tu repositorio ya cuenta con flujos de trabajo: En la esquina superior izquierda, da clic sobre Flujo de trabajo nuevo.
- Debajo del nombre de la plantilla que deseas utilizar, da clic en Configurar este flujo de trabajo.
Pasos siguientes
Para seguir aprendiendo sobre las GitHub Actions, consulta la sección "Compartir flujos de trabajo, secretos y ejecutores con tu organización".