Jakie są różnice między opcjami {przed _,} {instalacja, skrypt} .travis.yml?

Wewnątrz .travis.ymlpliku konfiguracyjnego, co jest praktyczna różnica pomiędzy before_install, install, before_scriptoraz scriptopcji?

Nie znalazłem dokumentacji wyjaśniającej różnice między tymi opcjami.

Nie musisz korzystać z tych sekcji, ale jeśli to zrobisz, przekazujesz zamiar tego, co robisz:

before_install:
  # execute all of the commands which need to be executed 
  # before installing dependencies
  - composer self-update
  - composer validate

install:
  # install all of the dependencies you need here
  - composer install --prefer-dist

before_script:
  # execute all of the commands which need to be executed 
  # before running actual tests
  - mysql -u root -e 'CREATE DATABASE test'
  - bin/doctrine-migrations migrations:migrate

script:
  # execute all of the commands which 
  # should make the build pass or fail
  - vendor/bin/phpunit
  - vendor/bin/php-cs-fixer fix --verbose --diff --dry-run

Zobacz na przykład https://github.com/localheinz/composer-normalize/blob/0.8.0/.travis.yml .

Różnica polega na stanie pracy, gdy coś idzie nie tak.

Git 2.17 (Q2 2018) ilustruje to w zatwierdzeniu 3c93b82 (08 stycznia 2018) autorstwa SZEDER Gábor ( szeder) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu c710d18 , 08 marca 2018 r.)}

Który ilustruje różnicę między praktyczną before_install, install, before_scriptoraz scriptopcji

travis-ci: buduj Gita w fazie „ script”

Odkąd zaczęliśmy budować i testować Git na Travis CI ( 522354d : Add Travis CI support, 2015-11-27, Git v2.7.0-rc0), tworzymy Git w fazie „ before_script” i uruchamiamy zestaw testów w „ script” fazy (z wyjątkiem późniejszych wprowadzonych zadań kompilacji dla 32-bitowego systemu Linux i Windows, w których budujemy w script„fazie”).

W przeciwieństwie do tego praktyka Travis CI polega na budowaniu i testowaniu w fazie „ script”; rzeczywiście, domyślnym poleceniem kompilacji Travis CI dla scriptfazy projektów C / C ++ jest:

./configure && make && make test

Powód, dla którego Travis CI robi to w ten sposób i dlaczego jest to lepsze podejście niż nasze, leży w kategoryzowaniu nieudanych prac budowlanych. Gdy coś poszło nie tak w budowaniu, jego stan może wyglądać następująco:

• „nie powiodło się” , jeśli polecenie w fazie „ script” zwróciło błąd.
  Wskazuje na to czerwony „X” w interfejsie internetowym Travis CI.

• „błąd” , jeśli polecenie w fazie „ before_install”, „ install” lub „ before_script” zwróciło błąd lub zadanie kompilacji przekroczyło limit czasu.
  Jest to pokazane jako czerwony „!” w interfejsie internetowym.

Ułatwia to zarówno ludziom przeglądającym interfejs sieciowy Travis CI, jak i zautomatyzowanym narzędziom wysyłającym zapytania do interfejsu API Travis CI, podjęcie decyzji, kiedy nieudana kompilacja jest naszym obowiązkiem wymagającym ludzkiej uwagi, tj. Kiedy zadanie kompilacji „nie powiodło się” z powodu kompilatora. błąd lub niepowodzenie testu, a gdy jest to spowodowane przez coś poza naszą kontrolą i może zostać naprawione przez ponowne uruchomienie zadania kompilacji, np. gdy zadanie kompilacji zostało „błędne”, ponieważ nie można było zainstalować zależności z powodu tymczasowego błędu sieci lub Zadanie kompilacji OSX przekroczyło limit czasu.

Wadą budowania Gita w fazie „ before_script” jest to, że trzeba sprawdzić dziennik śledzenia wszystkich „błędnych” zadań budowania, aby zobaczyć, co spowodowało błąd, ponieważ mógł być on spowodowany błędem kompilatora.
Wymaga to dodatkowych kliknięć i wczytywania stron w interfejsie internetowym oraz dodatkowej złożoności i żądań API w zautomatyzowanych narzędziach.

Dlatego przenieś budowanie Gita z fazy „ before_script” do fazy „ script”, odpowiednio aktualizując również nazwę skryptu.
' ci/run-builds.sh' teraz jest w zasadzie pusty, usuń go.
Kilka z naszych konfiguracji zadań kompilacji zastępuje domyślne ustawienie „ before_script”, aby nic nie robić; z tą zmianą nasze domyślne ' before_script' też nic nie zrobi, więc usuń również te nadrzędne dyrektywy.