Esta versión de GitHub Enterprise se discontinuó el 2021-09-23. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener un mejor desempeño, más seguridad y nuevas características, actualiza a la última versión de GitHub Enterprise. Para obtener ayuda con la actualización, contacta al soporte de GitHub Enterprise.

Administrar flujos de trabajo complejos

Esta guía te muestra cómo utilizar las características avanzadas de GitHub Actions con administración de secretos, jobs dependientes, almacenamiento en caché, matrices de compilación,y etiquetas.

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.


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.

  1. En GitHub Enterprise Server, visita la página principal del repositorio.
  2. Debajo del nombre de tu repositorio, da clic en Acciones. Pestaña de acciones en la navegación del repositorio principal
  3. Si tu repositorio ya cuenta con flujos de trabajo: En la esquina superior izquierda, da clic sobre Flujo de trabajo nuevo. Crear un nuevo flujo de trabajo
  4. Debajo del nombre de la plantilla que deseas utilizar, da clic en Configurar este flujo de trabajo. 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".