Как настроить Travis-CI для создания запросов получения по запросу и слияний к основному w/o дублированию

Question 1

Помещать его в условия "BDD":

Фон:
Учитывая я способствую GH repo

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

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

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

Я был смущен "нажатиями сборки Travis-CI" и "сборкой PRS" настройки, как:

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

Это объяснено больше в документах Travis-CI и выпуске № 3241 GH.

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

Question 2

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

Включают оба PRS & перейдите нажатия в настройках Travis для repo:

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

branches:
  only: 
    - master

Тест это путем создания PR с .travis.yml изменение и другой PR с некоторыми пустыми фиксациями для проверки его работы для ветвлений также .
Проверяют успешная сборка фиксации слияния от ведущего устройства .

Question 3

Question 4

Просто найденный в travis документы

Добавляют к .travis.yml

if: type = push

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

if: type = pull_request

Question 5

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

Сохраняют и "Нажатия сборки" и "Сборку, надевают запросы" НА [1 113]
, Добавляют branches:except директива к Вашему .travis.yml:
```
branches:
  except:
    - /^pr\..*/
```

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

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

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

временное ответвление WIP, совместно использованное несколькими разработчиками: wip.feature-A, любой соглашается на это ответвление, инициирует сборку
, когда ответвление готово быть объединенным с master, можно переименовать его от wip.feature-A до [1 110] и открыть запрос получения по запросу
, если при рассмотрении получения по запросу запросят хотеть применить новые меры, просто продвинуть к [1 111]

На всех шагах выше только одной сборки, то будет инициирован.

Question 6

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

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

Saugat Acharya · Accepted Answer · 31 October 2019 в 13:59

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

Включают оба PRS & перейдите нажатия в настройках Travis для repo:

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

branches:
  only: 
    - master

Тест это путем создания PR с .travis.yml изменение и другой PR с некоторыми пустыми фиксациями для проверки его работы для ветвлений также .
Проверяют успешная сборка фиксации слияния от ведущего устройства .

grosser · Answer 2 · 31 October 2019 в 13:59

Просто найденный в travis документы

Добавляют к .travis.yml

if: type = push

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

if: type = pull_request

10

ответ дан grosser 31 October 2019 в 13:59

score 2 · Answer 3 · 31 October 2019 в 13:59

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

Сохраняют и "Нажатия сборки" и "Сборку, надевают запросы" НА [1 113]
, Добавляют branches:except директива к Вашему .travis.yml:
```
branches:
  except:
    - /^pr\..*/
```

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

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

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

временное ответвление WIP, совместно использованное несколькими разработчиками: wip.feature-A, любой соглашается на это ответвление, инициирует сборку
, когда ответвление готово быть объединенным с master, можно переименовать его от wip.feature-A до [1 110] и открыть запрос получения по запросу
, если при рассмотрении получения по запросу запросят хотеть применить новые меры, просто продвинуть к [1 111]

На всех шагах выше только одной сборки, то будет инициирован.

John · Answer 4 · 31 October 2019 в 13:59

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

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

Как настроить Travis-CI для создания запросов получения по запросу и слияний к основному w/o дублированию

4 ответа

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

Другие вопросы по тегам:

Похожие вопросы: