Skip to main content

Optimización de CI para solicitudes de incorporación de cambios apiladas

Comprenda cómo GitHub Actions se ejecutan los flujos de trabajo para una pila, acceder a los metadatos de la pila en los flujos de trabajo y reducir el uso de CI redundante.

Nota:

Esta característica está en versión preliminar pública y está sujeta a cambios.

Cada solicitud de incorporación de cambios de una pila se evalúa como si tuviera como destino la base de la pila, como main. Esto mantiene la calidad coherente en cada capa, pero también significa que un flujo de trabajo se puede ejecutar muchas veces para una sola pila. En este artículo se explica cómo se ejecutan los flujos de trabajo para una pila y cómo reducir el uso de CI redundante.

Cómo se ejecutan los flujos de trabajo para una pila

GitHub Los flujos de trabajo de acciones se desencadenan como si cada solicitud de incorporación de cambios de la pila tenga como destino la base de la pila. Un flujo de trabajo configurado para ejecutarse en pull_request eventos que tienen como destino main las ejecuciones para cada solicitud de incorporación de cambios de la pila, no solo la inferior, por lo que no se requieren cambios de flujo de trabajo para que las comprobaciones se ejecuten en toda la pila.

Dado que un flujo de trabajo se ejecuta una vez por solicitud de incorporación de cambios, una pila grande multiplica el uso de CI. Sin embargo, puede usar metadatos de pila para ejecutar trabajos costosos solo cuando sean necesarios.

Acceso a los metadatos de la pila

Los metadatos de pila están disponibles en expresiones de flujo de trabajo a través de github.event.pull_request.stack. Esta propiedad solo está presente cuando la solicitud de incorporación de cambios pertenece a una pila, por lo que asegúrese de que los flujos de trabajo lo filtren antes de leer cualquiera de sus campos.

ExpressionDescription
github.event.pull_request.stack.numberEl número de la pila, con ámbito en el repositorio.
github.event.pull_request.stack.sizeNúmero total de solicitudes de incorporación de cambios en la pila.
github.event.pull_request.stack.positionPosición basada en 1 de esta solicitud de incorporación de cambios dentro de la pila (1 es la parte inferior).
github.event.pull_request.stack.base.refLa rama de toda la pila se dirige en última instancia, como main.
github.event.pull_request.stack.base.shaHEAD SHA de la rama base de la pila.

Por ejemplo, el siguiente flujo de trabajo lee los metadatos de la pila y ejecuta el segundo paso solo cuando la pila tiene como destino una rama cuyo nombre comienza por release/.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Show stack info
        if: github.event.pull_request.stack != null
        run: |
          echo "Stack base ref: ${{ github.event.pull_request.stack.base.ref }}"
          echo "PR ${{ github.event.pull_request.stack.position }} of ${{ github.event.pull_request.stack.size }} in the stack"

      - name: Run only when the stack targets a release branch
        if: github.event.pull_request.stack != null && startsWith(github.event.pull_request.stack.base.ref, 'release/')
        run: echo "This stack targets a release branch"

Reducción del uso de CI

Dado que un flujo de trabajo se ejecuta para cada solicitud de incorporación de cambios en una pila, puede usar los stack campos para ejecutar trabajos costosos solo en las posiciones que importan. Dos condiciones son especialmente útiles:

  • Solicitud de incorporación de cambios sin combinar más baja : la solicitud de incorporación de cambios actualmente en la parte inferior de la pila restante. Dado que tiene como destino la base de pila directamente, github.event.pull_request.stack.base.ref es igual a github.event.pull_request.base.ref.
  • Solicitud de incorporación de cambios superior: la última solicitud de incorporación de cambios de la pila, que contiene el conjunto completo de cambios. Es la solicitud de incorporación de cambios donde github.event.pull_request.stack.position es igual a github.event.pull_request.stack.size.
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Run for the lowest unmerged pull request in the stack
        if: github.event.pull_request.stack != null && github.event.pull_request.stack.base.ref == github.event.pull_request.base.ref
        run: echo "Lowest unmerged pull request in the stack"

      - name: Run for the top pull request in the stack
        if: github.event.pull_request.stack != null && github.event.pull_request.stack.position == github.event.pull_request.stack.size
        run: echo "Top pull request in the stack"

A medida que las solicitudes de incorporación de cambios se combinan de abajo arriba, cambia la solicitud de incorporación de cambios sin combinar más baja. Una vez que llega la solicitud de incorporación de cambios inferior, la siguiente solicitud de incorporación de cambios se vuelve a basar para dirigirse directamente a la base de pila, por lo que se convierte en la nueva solicitud de incorporación de cambios sin combinar más baja en la siguiente ejecución de flujo de trabajo.

También puede realizar la puerta en la solicitud de incorporación de cambios inferior original con github.event.pull_request.stack.position == 1, o en cualquier capa específica mediante position.