Optimieren von CI für gestapelte Pull Requests

Jeder Pull Request in einem Stapel wird so ausgewertet, als ob er gegen die Basis des Stapels gerichtet ist, wie z. B. main. Dadurch bleibt die Qualität auf jeder Ebene konsistent, bedeutet aber auch, dass ein Workflow viele Male für einen einzelnen Stack ausgeführt werden kann. In diesem Artikel wird erläutert, wie Workflows für einen Stack ausgeführt werden und wie Sie die redundante CI-Nutzung reduzieren.

Wie Workflows für einen Stapel ausgeführt werden

GitHub Actions-Workflows lösen aus, als ob jede Pull Request im Stapel auf die Basis des Stapels ausgerichtet ist. Ein Workflow, der so konfiguriert ist, dass er bei pull_request-Ereignissen für main ausgeführt wird, läuft für jede Pull Request im Stack, nicht nur für die unterste, sodass keine Änderungen am Workflow erforderlich sind, damit Ihre Prüfungen über den gesamten Stack hinweg ausgeführt werden.

Da ein Workflow einmal pro Pull Request ausgeführt wird, vervielfacht ein großer Stack Ihre CI-Nutzung. Sie können jedoch Stack-Metadaten verwenden, um teure Jobs nur dort auszuführen, wo sie benötigt werden.

Zugriff auf Stapelmetadaten

Stapelmetadaten sind in Workflowausdrücken über github.event.pull_request.stack verfügbar. Diese Eigenschaft ist nur vorhanden, wenn der Pull Request zu einem Stapel gehört. Stellen Sie daher sicher, dass Ihre Workflows vorher auf diese Eigenschaft prüfen, bevor sie eines ihrer Felder lesen.

Ausdruck	Beschreibung
github.event.pull_request.stack.number	Die Nummer des Stapels, die auf das Repository beschränkt ist.
github.event.pull_request.stack.size	Gesamtanzahl der Pull Requests im Stapel.
github.event.pull_request.stack.position	Position, beginnend bei 1, dieses Pull Requests innerhalb des Stacks (1 ist unten).
github.event.pull_request.stack.base.ref	Der Branch, auf den der gesamte Stack letztlich abzielt, wie z. B. main.
github.event.pull_request.stack.base.sha	HEAD SHA des Basiszweigs des Stapels.

Der folgende Workflow liest beispielsweise Stapelmetadaten und führt den zweiten Schritt nur aus, wenn der Stapel einen Branch als Ziel hat, dessen Name mit release/ beginnt.

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"

Reduzierung der CI-Nutzung

Da ein Workflow für jeden Pull Request in einem Stack ausgeführt wird, können Sie die stack Felder verwenden, um teure Jobs nur an den wichtigen Positionen auszuführen. Zwei Bedingungen sind besonders nützlich:

• Niedrigster nicht zusammengeführter Pull Request — der Pull Request, der sich derzeit am unteren Ende des verbleibenden Stapels befindet und direkt auf die Stapelbasis abzielt. Es ist der Pull Request, wobei github.event.pull_request.stack.base.ref gleich github.event.pull_request.base.ref ist.
• Oberste Pull Request – die letzte Pull Request im Stapel, die den vollständigen Satz von Änderungen enthält. Es ist der Pull-Request, wobei github.event.pull_request.stack.position gleich github.event.pull_request.stack.size ist.

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"

Wenn Pull Requests von unten nach oben zusammengeführt werden, ändert sich der unterste noch nicht zusammengeführte Pull Request. Sobald der untere Pull Request zusammengeführt wurde, wird der nächste Pull Request so neu basiert, dass er direkt auf die Stapelbasis ausgerichtet ist, sodass er beim folgenden Workflowlauf zum neuen untersten nicht zusammengeführten Pull Request wird.

Sie können das Gate auch für den ursprünglichen Basis-Pull Request mit github.event.pull_request.stack.position == 1 oder für einen bestimmten Layer mit position festlegen.