Куда подтолкнуть провальный тест?

Я только что изменил настройки веток в своем репозитории GitHub, так что моя [следующая] ветвь требует прохождения сборки CI через запрос на получение.

Затем последовало обсуждение с несколькими членами команды о неудачных тестах.

Ради контекста ...

Хранилище имеет [мастер] ветвь , которая только PR'd в когда есть релиз, так [мастер] содержит код от последнего релиза, независимо от того, является ли оно основным, несовершеннолетним, исправление, бета, альфа / предварительная сборка.

Ветвь [next] является веткой «по умолчанию», где мы намереваемся сохранить «готовый к выпуску» код; технически эта ветвь может быть в любое время PR-директором [master] и выпущена.

Отдельные форки имеют свои собственные ветки разработчиков и PR для [следующего].

Когда я просматриваю нетривиальный PR, я объединяю ветку разработчика для своей ветки "review", и, если я вижу вещи, которые можно быстро исправить, я фиксирую / подталкиваю изменения и новые (иногда неудачные) тесты, а также PR обратно в ветку разработчика; когда они объединяют мои изменения, пропускают новые неудачные тесты, а затем нажимают, их PR синхронизируется, и затем я объединяю PR в [следующий].

Но этот вопрос не про прохождение тестов, а про провал .

Неудачные тесты документируют, что нужно исправить.

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

Технически список проблем GitHub (отфильтрованный по ошибкам и / или критическим меткам ) тоже делает это. Это хорошая практика , чтобы также иметь кучу неудачи тестов с ошибками документа?

Неудачная сборка [next] будет означать, что мы не готовы к выпуску ... но тогда "быть готовым к выпуску" - это что-то вроде "быть готовым" иметь детей - вы никогда не будете полностью готовы к этому, и что-то, где-то (переменной важности) неизбежно пойдет не так с выпуском.

Так что мы только подталкиваем проходящие тесты к [следующему]. Куда подтолкнуть провальные тесты тогда? Я имею в виду вне PR / процесса обзора?

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

Куда я должен подталкивать эти провальные тесты? Или это даже хорошая идея, чтобы подтолкнуть неудачные тесты в любом месте?

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

Если вы также пометите каждый тест ссылкой для отслеживания проблем для устранения проблемы, это даст вам простой способ связать вещи вместе.

Полное раскрытие: я один из участников дискуссии.

Основная ветвь хранилища не является его главной ветвью. Слияние с мастером не служит какой-либо «реальной цели», и эта ветвь не выполняет то, что должна делать ветвь (а именно, перемещается ).
Вы используете эту ветку как тег для последней версии.

Вместо использования ветки используйте тег. Когда вы хотите выпустить релиз, вы делаете необходимые шаги в «Release-Branch», как ветка темы. Затем вы объединяете это с [next] и добавляете тег.

Роль, которую [следующий] выполняет, это роль главной ветви. Только готовый к выпуску код входит туда. Все остальное будет [развиваться] веткой. Ветвь разработки содержит работу, которая должна быть стабилизирована . Это значит: удалить [master], переназначить [next], как вы уже сделали, и создать еще одну ветку для «менее стабильной» работы.

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