Управление очередью слияния

Сведения об очередях слияния

Очередь слияния помогает повысить скорость, автоматив объединение запросов на вытягивание в занятую ветвь и гарантируя, что ветвь никогда не прерывается несовместимыми изменениями.

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

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

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

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

Дополнительные сведения о слиянии запроса на вытягивание с помощью очереди слияния см. в разделе Слияние для запроса на вытягивание с очередью слияния.

Настройка рабочих процессов непрерывной интеграции (CI) для очередей слиянием

Активация проверок группы слияния с помощью GitHub Actions

Событие необходимо использовать merge_group для активации рабочего процесса GitHub Actions при добавлении запроса на вытягивание в очередь слияния.

Рабочий процесс, сообщающий о проверке, которая требуется для защиты целевой ветви, будет выглядеть следующим образом:

on:
  pull_request:
  merge_group:

Дополнительные сведения о событии см. в merge_group разделе События, инициирующие рабочие процессы.

Активация проверок группы слиянием с сторонними поставщиками CI

При использовании сторонних поставщиков CI необходимо обновить конфигурацию CI, чтобы запуститься при отправке ветвь, которая начинается с специального префикса gh-readonly-queue/{base_branch} . Это временные ветви, созданные от вашего имени очередью слияния, и содержат разные sha от запроса на вытягивание.

Управление очередью слияния

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

После включения параметра "Требовать очередь слияния" можно также получить доступ к следующим параметрам:

• Метод слияния: выберите метод, используемый при слиянии запросов на вытягивание в очереди: слияние, перебазирование или скваш.

• Параллелизм сборки: максимальное количество веб-перехватчиков для отправки (между 1 и100), регулирование общего объема merge_group параллельных сборок CI. Это влияет на скорость слияний, которые может завершить очередь слияния.

• Только слияние неисправных запросов на вытягивание. Этот параметр определяет способ объединения групп очередей слиянием для объединения запросов на вытягивание.

  Включено?	Description
  Да	Все запросы на вытягивание должны соответствовать необходимым проверкам, которые необходимо объединить.
  No	Запросы на вытягивание, не прошедшие обязательные проверки, можно добавить в группу до тех пор, пока последний запрос на вытягивание в группе прошел необходимые проверки. Если последний запрос на вытягивание в группе прошел необходимые проверки, это означает, что проверки прошли для объединенного набора изменений в группе слиянием. Если этот флажок не выбран, может оказаться полезным, если у вас есть периодические сбои теста, но не требуется, чтобы ложные отрицательные значения удерживали очередь.

• Время ожидания проверки состояния: выберите время ожидания очереди ответа от CI, прежде чем предположить, что проверки завершились сбоем.

• Ограничения слияния: выберите минимальное и максимальное количество запросов на вытягивание для объединения в базовая ветвь одновременно (между 1 и100), а время ожидания очереди должно перестать ожидать больше записей и объединяться с меньшим числом.

  Note

  Ограничения слияния не объединяют merge_group сборки. Ограничения слияния влияют только на слияние в базовая ветвь один или несколько merge_group проверок сборки.

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

Как работают очереди слияния

Так как запросы на вытягивание добавляются в очередь слияния, очередь слияния гарантирует, что они объединяются в порядке первого в первом запуске, где всегда удовлетворены необходимые проверки.

Очередь слияния создает временные ветви с специальным префиксом для проверки изменений запроса на вытягивание. При добавлении запроса на вытягивание в очередь слияния изменения в запросе на вытягивание группируются в merge_group последнюю версию base_branch , а также изменения из запросов на вытягивание перед ним в очереди. GitHub Enterprise Server объединяет все эти изменения в base_branch после проверки, необходимые защитой base_branch ветви.

Сведения о методах слияния см. в разделе Сведения о слиянии запросов на вытягивание.

Успешный CI

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

1. Пользователь добавляет запрос на вытягивание #1 в очередь слияния.
2. Очередь слияния создает временную ветвь с префиксом main/pr-1 , который содержит изменения кода из целевой ветви и запроса на вытягивание #1. merge_group Событие checks_requested типа веб-перехватчика отправляется, и очередь слияния ожидает ответа от поставщика CI.
3. Пользователь добавляет запрос на вытягивание #2 в очередь слияния.
4. Очередь слияния создает временную ветвь с префиксом main/pr-2 , который содержит изменения кода из целевой ветви, запроса на вытягивание #1 и запроса на вытягивание #2 и отправки веб-перехватчиков.
5. Когда API GitHub Enterprise Server получает успешные ответы CI для merge_group ветвей и main/pr-2временная ветвь будет объединена в целевую ветвь main/pr-1 main/pr-2. Целевая ветвь теперь содержит оба изменения из запроса на вытягивание #1 и #2.

Сбой CI

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

В следующем сценарии описывается, что происходит, когда CI сообщает о состоянии сбоя в одном запросе на вытягивание.

1. Пользователь добавляет запрос на вытягивание #1 в очередь слияния.
2. Очередь слияния создает временную ветвь с префиксом main/pr-1 , который содержит изменения кода из целевой ветви и запроса на вытягивание #1. merge_group Событие checks_requested типа веб-перехватчика отправляется, и очередь слияния ожидает ответа от поставщика CI.
3. Пользователь добавляет запрос на вытягивание #2 в очередь слияния.
4. Очередь слияния создает временную ветвь с префиксом main/pr-2 , который содержит изменения кода из целевой ветви, запроса на вытягивание #1 и запроса на вытягивание #2 и отправки веб-перехватчиков.
5. Когда API GitHub Enterprise Server получает состояние main/pr-1сбоя, очередь слияния автоматически удаляет запрос на вытягивание #1 из очереди слияния.
6. Очередь слияния повторно создает временную ветвь с префиксом main/pr-2 только для хранения изменений из целевой ветви и запроса на вытягивание #2.
7. Когда API GitHub Enterprise Server получает успешные ответы CI для merge_group ветви, временная ветвь main/pr-2 будет объединена в целевую ветвь main/pr-2без запроса на вытягивание #1.

Переход в верхнюю часть очереди

При добавлении запроса на вытягивание в очередь слияния можно переместить запрос на вытягивание в верхней части очереди.

В следующем сценарии описывается, что происходит при переходе пользователя к очереди.

1. Пользователь добавляет запрос на вытягивание #1 в очередь слияния.
2. Очередь слияния создает временную ветвь с префиксом main/pr-1 , который содержит изменения кода из целевой ветви и запроса на вытягивание #1. merge_group Событие checks_requested типа веб-перехватчика отправляется, и очередь слияния ожидает ответа от поставщика CI.
3. Пользователь добавляет запрос на вытягивание #2 в очередь слияния.
4. Очередь слияния создает временную ветвь с префиксом main/pr-2 , который содержит изменения кода из целевой ветви, запроса на вытягивание #1 и запроса на вытягивание #2 и отправки веб-перехватчиков.
5. Пользователь добавляет запрос на вытягивание #3 в очередь слияния с параметром перехода, который представляет разрыв в графе фиксации.
6. Очередь слияния создает временную ветвь с префиксом main/pr-3 , который содержит изменения кода из целевой ветви и запроса на вытягивание #3, а также отправляет веб-перехватчики.
7. Очередь слияния повторно создает временные ветви с префиксом main/pr-1 и main/pr-2 содержит изменения из запроса на вытягивание #3 и отправляет веб-перехватчики.

Дополнительные материалы

• Слияние для запроса на вытягивание с очередью слияния
• Сведения о защищенных ветвях