Оптимизация CI для запросов на вытягивание с накоплением

Каждый запрос на вытягивание в стеке вычисляется так, как если бы он предназначен для базы стека, например main. Это обеспечивает согласованность качества для каждого слоя, но также означает, что рабочий процесс может выполняться несколько раз для одного стека. В этой статье объясняется, как рабочие процессы выполняются для стека и как сократить избыточное использование CI.

Запуск рабочих процессов для стека

GitHub Рабочие процессы действий активируются так, как если бы каждый запрос на вытягивание в стеке предназначен для базы стека. Рабочий процесс, настроенный для запуска pull_request событий, предназначенных main для каждого запроса на вытягивание в стеке, а не только нижнего, поэтому для выполнения проверок во всем стеке не требуется никаких изменений рабочего процесса.

Так как рабочий процесс выполняется один раз на запрос на вытягивание, большой стек умножает использование CI. Однако можно использовать метаданные стека для выполнения дорогостоящих заданий только в тех случаях, когда они необходимы.

Доступ к метаданным стека

Метаданные стека доступны в выражениях рабочих процессов с помощью github.event.pull_request.stack. Это свойство присутствует только в том случае, если запрос на вытягивание принадлежит стеку, поэтому убедитесь, что рабочие процессы фильтруют его перед чтением любого из его полей.

Expression	Description
github.event.pull_request.stack.number	Номер стека, ограниченный в репозитории.
github.event.pull_request.stack.size	Общее количество запросов на вытягивание в стеке.
github.event.pull_request.stack.position	1-е положение запроса на вытягивание в стеке (1 в нижней части).
github.event.pull_request.stack.base.ref	Ветвь всего стека в конечном итоге нацелена, например main.
github.event.pull_request.stack.base.sha	HEAD SHA базовой ветви стека.

Например, следующий рабочий процесс считывает метаданные стека и выполняет второй шаг, только если стек предназначен для ветви, имя которой начинается с 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"

Сокращение использования CI

Так как рабочий процесс выполняется для каждого запроса на вытягивание в стеке, можно использовать stack поля для выполнения дорогостоящих заданий только в позициях, которые имеют значение. Два условия особенно полезны:

• Самый низкий необъединяемый запрос на вытягивание — запрос на вытягивание в настоящее время в нижней части оставшегося стека. Так как он предназначен для базы стека напрямую, github.event.pull_request.stack.base.ref равно github.event.pull_request.base.ref.
• Верхний запрос на вытягивание — последний запрос на вытягивание в стеке, содержащий полный набор изменений. Это запрос на вытягивание, github.event.pull_request.stack.sizeгде github.event.pull_request.stack.position равно.

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"

При слиянии запросов на вытягивание снизу вверх наименьшие изменения в запросе на вытягивание. После того как нижний запрос на вытягивание приземляется, следующий запрос на вытягивание перебазируется, чтобы напрямую нацеливаться на базу стека, поэтому он становится новым самым низким запросом на вытягивание при выполнении следующего рабочего процесса.

Вы также можете включить в исходный запрос на вытягивание внизу или github.event.pull_request.stack.position == 1на любом определенном слое с помощью position.