Jak skonfigurować Travis-CI do budowania pull requests & merges do master bez redundancji

Question

Jak skonfigurować Travis-CI do budowania pull requests & merges do master bez redundancji

Aby ująć to w słowach "BDD":

Background:
Given I ' m contributing to a GH repo

Kiedy tworzę pull request
Następnie Travis powinien zbudować najnowszy commit

Kiedy naciskam na istniejące żądanie pull
Następnie Travis powinien zbudować najnowszy commit

Kiedy scalam pull request Do master
Wtedy Travis powinien zbudować mistrza

Byłem zdezorientowany ustawieniami "build Push" I "build PRs, as:

włączenie obu powoduje, że każde żądanie Pull zostanie zbudowane dwa razy przez Travisa
- raz za commit na tej gałęzi
- i po raz kolejny dla merge commit tej gałęzi do jej przeznaczenia
włączenie tylko "build PRs" powoduje, że PRs jest budowany, ale nie powoduje kompilacji Post-merge (np. na master).
Umożliwienie" wypycha " brute-force spełnia powyższe kryteria budując wszystkie wypycha do repo. Możesz spróbować finagle rzeczy według białej i czarnej listy gałęzi, ale to prawdopodobnie cię ugryzie, chyba że jesteś rygorystycznie zdyscyplinowany z nazwami gałęzi.

Jest to wyjaśnione bardziej w Travis-CI docs i GH issue #3241 .

Ktoś zna konfigurację spełniającą powyższe kryteria?

42

github travis-ci pull-request

Author: Brian Gerstle, 2015-08-07

Source

4 answers

Just found in travis docs

Dodaj do .travis.yml

if: type = push

Alternatywnie:

if: type = pull_request

3

Author: grosser,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-12-08 01:28:47

Podejście do białej listy opisane w zaakceptowanej odpowiedzi ma pewne istotne ograniczenia. W szczególności nie obsługuje on nieadekwatnie budowania arbitralnych oddziałów bez otwierania PR.

Otworzyłemproblem z prośbą o lepsze rozwiązanie .

2

Author: John,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-11-28 23:18:15

Możesz użyć next workflow, jeśli chcesz przetestować nie tylko gałąź master, ale także kilka innych gałęzi:

Zachowaj zarówno "Build push", jak I "build pull requests" na
Dodaj branches:except do swojego .travis.yml:
```
branches:
  except:
    - /^pr\..*/
```

W tej konfiguracji:

każdy commit do gałęzi feature-A uruchomi build
każdy commit do gałęzi pr.feature-A nie uruchomi kompilacji
jeśli branch pr.feature-A jest używany w Open pull request, to build zostanie uruchomiony

Przykład przepływu pracy

tymczasowa gałąź WIP współdzielona pomiędzy kilku deweloperów: wip.feature-A, każdy commit do tej gałęzi uruchomi kompilację
kiedy branch jest gotowy do scalenia do master możesz zmienić jego nazwę z wip.feature-A na pr.feature-A i otworzyć pull request
jeśli podczas przeglądania pull request chcesz zastosować nowe poprawki, po prostu naciśnij pr.feature-A

Na wszystkich powyższych krokach zostanie uruchomiona tylko jedna kompilacja.

2

Author: ,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-01-18 09:34:00

score 72 · Accepted Answer

W końcu znalazłem kolejny problem z GH(#2111) co dało mi pomysł, aby spróbować włączyć zarówno PRs i push, ale z białą listą, aby ograniczyć push do określonej gałęzi. Wydaje się, że spełnia to kryteria dla mojego przepływu pracy. Oto co zrobiłem:

Włącz zarówno PRS jak i branch w Ustawieniach repo:

Zmień .travis.yml na white-list master branch (tzn. tylko build wypycha do mistrz): {]}

branches:
  only: 
    - master

Przetestuj go, tworząc PR ze zmianą .travis.yml , a inny PR z pustymi zatwierdzeniami, aby go zweryfikować działa również dla forków.
Zweryfikuj pomyślne scalanie kompilacji z master .