У нас есть github enterprise 2.13.4.
Для определенного репо у нас есть ряд проверок статуса. Я не администратор репо, поэтому у меня нет доступа к определению самих чеков.
Одна из проверок выполняет сборку на Jenkins.
Для этого репо слияния не допускаются, если ветка не обновлена.
Для сборки, которая выполняется на Jenkins, есть несколько сценариев devops, которые облегчают сборку, и один из этих сценариев прерывает сборку, когда определяет, что ветвь устарела.
Проблема заключается в том, что для достижения этого результата требуется пара минут, а из-за этого точного сценария для общего списка сборок на этом сервере Jenkins произошел сбой половины, загромождающий список сборок для этого задания.
Желаемое поведение для этих PR:
- сохранить принудительное невыполнение до тех пор, пока не обновится
- сохранить принудительное выполнение всех проверок состояния, проходящих до слияния
- условно запустить проверку состояния «сборки», только если ветка уже обновлена. Если создатель PR создает его устаревшим с целевой веткой, он может просто обновить его и выполнить «еще раз, пожалуйста» и т. Д.
Сейчас сборка в любом случае прерывается через пару минут потраченного впустую времени на агенте сборки, прежде чем перейти к чему-либо значимому, поэтому я не думаю, что то, что я предлагаю, удалит любую ценную информацию (ошибку компиляции и т. Д.), Которая было бы предоставлено на строительство филиала, даже если он устарел.