Как настроить Travis-CI для создания запросов на загрузку и слияния для управления без резервирования

Чтобы включить его в термины "BDD":

Фон:
Учитывая, что я вношу свой вклад в репозиторий GH

Когда я создаю запрос на перенос
Затем Travis должен построить последнюю фиксацию

Когда я нажимаю на существующий запрос на тягу
Затем Travis должен построить последнюю фиксацию

Когда я сжимаю запрос на тягу, чтобы освоить
Затем Тревис должен построить мастер

Меня смутили настройки Travis-CI "build push" и "build PRs", как:

Включение обоих причин, по которым каждый запрос Pull будет дважды создан Travis
- один раз для фиксации на этой ветке
- и еще раз для фиксации слияния этой ветки в пункт назначения
Включение только "создания PR" приводит к тому, что PR-серверы должны быть созданы, но не приводят к сборке после слияния (т.е. на главном сервере).
Включение "толкает" грубую силу удовлетворяет вышеуказанным критериям, создавая все нажатия на репо. Вы можете попытаться окупить вещи белыми и черными списками, но это, вероятно, укусит вас, если вы строго дисциплинированы именами ветвей.

Это объясняется больше в Travis-CI docs и проблеме GH № 3241.

Кто-нибудь знает конфигурацию, которая удовлетворяет вышеуказанным критериям?

Ответы

Ответ 1

В итоге я нашел еще одну проблему GH (# 2111), которая дала мне идею попробовать включить PR и push, но с белым списком ограничивает нажатие на конкретную ветвь. Это, похоже, удовлетворяет критериям моего рабочего процесса. Вот что я сделал:

Включить оба PR и ответвления в настройках Travis для репо:

Измените .travis.yml на белый список master ветвь (т.е. только создайте нажатие для запуска):

branches:
  only: 
    - master

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

Ответ 2

Только что найденный в документах travis

Добавить к .travis.yml

if: type = push

альтернативно:

if: type = pull_request

Ответ 3

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

Я открыл проблему, требующую лучшего решения.

Ответ 4

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

Храните как "Build push", так и "Build pull request" ON
Добавьте директиву branches:except к вашему .travis.yml:
```
branches:
  except:
    - /^pr\..*/
```

В этой конфигурации:

любая фиксация для ветки feature-A вызовет сборку
любая фиксация для ветки pr.feature-A не приведет к созданию сборки
если ветвь pr.feature-A используется в открытом запросе на pull, тогда будет запущена сборка

Пример рабочего процесса

временная ветвь WIP, совместно используемая несколькими разработчиками: wip.feature-A, любая фиксация этой ветки вызовет сборку
Когда ветка готова к объединению с master, вы можете переименовать ее с wip.feature-A в pr.feature-A и открыть запрос на pull
Если при просмотре запроса на тягу вы хотите применить новые исправления, просто нажмите на pr.feature-A

На всех шагах выше будет запущена только одна сборка.

Ответ 5

Предполагая, что вы хотите построить все PR, что-то вроде следующего сделает свое дело. Включите как ветку, так и сборку PR на странице настроек, и поместите эту строку в качестве первой строки в вашем travis.yml:

if: (type = push AND branch IN (master, dev)) OR (type = pull_request AND NOT branch =~/no-ci/)

При этом будет предпринята попытка принудительной сборки на всех нажатиях, а сборка PR на всех нажатиях - к открытому PR, но будет отфильтрован любой, который не соответствует условию. Возможно, вам придется немного изменить это - предложение о том, чтобы не создавать ветки с no-ci где-то в их названии, очевидно, является необязательным, и у вас может не быть двух ветвей, на которых вы всегда хотите запускать сборки.

Вы можете прочитать больше об условиях и условных сборках на сайте Travis.