Skip to main content

Enterprise Server 3.15 actualmente está disponible como versión candidata para lanzamiento.

Automatizar al Dependabot con las GitHub Actions

Ejemplos de cómo puedes utilizar las GitHub Actions para automatizar las tareas comunes relacionadas con el Dependabot.

¿Quién puede utilizar esta característica?

People with write permissions to a repository can configure GitHub Actions to respond to Dependabot-created pull requests.

Nota: Para poder utilizar esta característica, el administrador del sitio debe configurar Dependabot updates para tu instancia de GitHub Enterprise Server. Para obtener más información, vea «Habilitación de Dependabot para la empresa».

Es posible que no puedas habilitar o deshabilitar Dependabot updates si un propietario de empresa ha establecido una directiva en el nivel empresarial. Para más información, consulta "Aplicación de directivas de seguridad y análisis de código de la empresa".

Acerca del Dependabot y de las GitHub Actions

El Dependabot crea las solicitudes de cambios para mantener actualizadas tus dependencias y puedes utilizar las GitHub Actions para llevar a cabo tareas automatizadas cuando se creen estas solicitudes de cambios. Por ejemplo, recupera artefactos adicionales, agrega etiquetas, ejecuta pruebas o modifica la solicitud de cambios de cualquier otra forma.

Responder a los eventos

El Dependabot puede activar flujos de trabajo de las GitHub Actions en sus solicitudes de cambios y comentarios; sin embargo, algunos eventos se tratan de forma distinta.

En el caso de los flujos de trabajo iniciados por Dependabot (github.actor == 'dependabot[bot]') mediante los eventos pull_request, pull_request_review, pull_request_review_comment, push, create, deployment y deployment_status, se aplican las restricciones siguientes:

  • GITHUB_TOKEN tiene permisos de solo lectura de manera predeterminada.
  • Los secretos se llenan desde los secretos del Dependabot. Los secretos de las GitHub Actions no están disponibles.

En el caso de los flujos de trabajo iniciados por Dependabot (github.actor == 'dependabot[bot]') mediante el evento pull_request_target, si la referencia base de la solicitud de incorporación de cambios se ha creado mediante Dependabot (github.event.pull_request.user.login == 'dependabot[bot]'), el valor GITHUB_TOKEN será de solo lectura y los secretos no estarán disponibles.

Estas restricciones se aplican incluso si un actor diferente vuelve a ejecutar el flujo de trabajo.

Para más información, vea “Mantenimiento de la seguridad de flujos de trabajo y Acciones de GitHub: prevención de solicitudes pwn”.

Cambio de permisos GITHUB_TOKEN

De manera predeterminada, los flujos de trabajo de GitHub Actions desencadenados por Dependabot obtienen un valor GITHUB_TOKEN con permisos de solo lectura. Puede usar la clave permissions del flujo de trabajo para aumentar el acceso del token:

name: CI
on: pull_request

# Set the access for individual scopes, or use permissions: write-all
permissions:
  pull-requests: write
  issues: write
  repository-projects: write
  ...

jobs:
  ...

Para obtener más información, vea «Autenticación automática de tokens».

Acceder a los secretos

Cuando un evento del Dependabot activa un flujo de trabajo, los únicos secretos disponibles para dicho flujo de trabajo son los del Dependabot. Los secretos de las GitHub Actions no están disponibles. Por lo tanto, debes almacenar cualquier secreto que utilice un flujo de trabajo activado mediante los eventos del Dependabot como secretos del Dependabot. Para obtener más información, vea «Configuración del acceso a registros privados para Dependabot».

Los secretos de Dependabot se agregan al contexto secrets y se les hace referencia mediante la misma sintaxis exacta que la de los secretos para GitHub Actions. Para obtener más información, vea «Uso de secretos en Acciones de GitHub».

Si tienes un flujo de trabajo que se activará mediante el Dependabot y también mediante otros actores, la solución más simple es almacenar el token con los permisos requeridos en una acción y en un secreto del Dependabot con nombres idénticos. Entonces, el flujo de trabajo puede incluir una llamada simple a estos secretos. Si el secreto del Dependabot tiene un nombre diferente, utiliza condiciones para especificar los secretos correctos para que los utilicen los diferentes actores. Para obtener ejemplos de condiciones de uso, vea "Automatizaciones comunes" a continuación.

Para acceder a un registro de contenedor privado en AWS con un nombre de usuario y una contraseña, un flujo de trabajo debe incluir un secreto para username y password. En el ejemplo siguiente, cuando Dependabot desencadena el flujo de trabajo, se usan los secretos de Dependabot con los nombres READONLY_AWS_ACCESS_KEY_ID y READONLY_AWS_ACCESS_KEY. Si otro actor activa el flujo de trabajo, se utilizarán los secretos de las acciones con estos nombres.

name: CI
on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Login to private container registry for dependencies
        uses: docker/login-action@3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c
        with:
          registry: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
          username: ${{ secrets.READONLY_AWS_ACCESS_KEY_ID }}
          password: ${{ secrets.READONLY_AWS_ACCESS_KEY }}

      - name: Build the Docker image
        run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)

Volver a ejecutar un flujo de trabajo manualmente

Cuando vuelvas a ejecutar manualmente un flujo de trabajo de Dependabot, se ejecutará con los mismos privilegios que antes incluso si el usuario que inició la nueva ejecución tiene otros privilegios. Para obtener más información, vea «Volver a ejecutar flujos de trabajo y jobs».

Automatizaciones comunes del Dependabot

Aquí mostramos varios escenarios comunes que pueden automatizarse utilizando las GitHub Actions.

Recuperar metadatos de una solicitud de cambios

Automatizar mucho requiere saber información del contenido de la solicitud de cambios: cuál era el nombre de la dependencia, si es una dependencia productva y si es una actualización de parche menor o mayor.

La acción dependabot/fetch-metadata proporciona toda esa información de forma automática:

name: Dependabot fetch metadata
on: pull_request

permissions:
  pull-requests: write
  issues: write
  repository-projects: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      # The following properties are now available:
      #  - steps.metadata.outputs.dependency-names
      #  - steps.metadata.outputs.dependency-type
      #  - steps.metadata.outputs.update-type

Para más información, vea el repositorio dependabot/fetch-metadata.

Etiquetar una solicitud de cambios

Si tienes otros flujos de trabajo de automatización o clasificación que se basen en etiquetas de GitHub, puedes configurar una acción para asignar etiquetas con base en los metadatos proporcionados.

Por ejemplo, si quieres etiquetar todas las actualizaciones de las dependencias de producción con una etiqueta:

name: Dependabot auto-label
on: pull_request

permissions:
  pull-requests: write
  issues: write
  repository-projects: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Add a label for all production dependencies
        if: steps.metadata.outputs.dependency-type == 'direct:production'
        run: gh pr edit "$PR_URL" --add-label "production"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}

Aprobar una solicitud de cambios

Si quieres aprobar las solicitudes de cambios del Dependabot automáticamente, puedes utilizar el GitHub CLI en un flujo de trabajo:

name: Dependabot auto-approve
on: pull_request

permissions:
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Approve a PR
        run: gh pr review --approve "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GH_TOKEN: ${{secrets.GITHUB_TOKEN}}

Habilita la fusión automática en una solicitud de cambios

Si quieres permitir que los mantenedores marquen determinadas solicitudes de incorporación de cambios para la fusión mediante combinación automática, puedes usar la funcionalidad de fusión mediante combinación automática de GitHub. Esto habilita a la solicitud de cambios para que se fusione cuando se cumpla cualquier prueba y aprobación requerida por las reglas de protección de rama. Para obtener más información, vea «Fusionar una solicitud de cambios automáticamente» y «Administrar una regla de protección de rama».

Como alternativa a las reglas de protección de ramas, puede crear conjuntos de reglas. Para más información, consulta "Acerca de los conjuntos de reglas".

Nota: Si usas comprobaciones de estado para probar las solicitudes de incorporación de cambios, debes habilitar Requerir comprobaciones de estado superadas antes de la fusión para la rama de destino para las solicitudes de incorporación de cambios Dependabot. Esta regla de protección de rama garantiza que las solicitudes de incorporación de cambios no se fusionan a menos que se superen todas las comprobaciones de estado necesarias. Para obtener más información, vea «Administrar una regla de protección de rama».

En su lugar, puedes usar GitHub Actions y GitHub CLI. Este es un ejemplo que combina automáticamente todas las actualizaciones de revisión de my-dependency:

name: Dependabot auto-merge
on: pull_request

permissions:
  contents: write
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Enable auto-merge for Dependabot PRs
        if: contains(steps.metadata.outputs.dependency-names, 'my-dependency') && steps.metadata.outputs.update-type == 'version-update:semver-patch'
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GH_TOKEN: ${{secrets.GITHUB_TOKEN}}

Solucionar los problemas de las ejecuciones de flujo de trabajo fallidas

Si tu ejecución de flujo de trabajo falla, verifica lo siguiente:

  • Estás ejecutando el flujo de trabajo únicamente cuando el actor adecuado lo activa.
  • Va a extraer del repositorio el ref correcto para pull_request.
  • Tus secretos están disponibles en los secretos del Dependabot, en vez de como secretos de las GitHub Actions.
  • Tiene un GITHUB_TOKEN con los permisos correctos.

Para obtener información sobre cómo escribir y depurar GitHub Actions, vea "Escritura de flujos de trabajo".