В чем разница между параметрами {before _,} {install, script} .travis.yml?

Внутри .travis.ymlфайла конфигурации , что практическая разница между before_install, install, before_scriptи scriptвариантов?

Я не нашел документации, объясняющей различия между этими параметрами.

Вам не обязательно использовать эти разделы, но если вы это сделаете, вы сообщаете о намерении того, что делаете:

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

См., Например, https://github.com/localheinz/composer-normalize/blob/0.8.0/.travis.yml .

Разница заключается в состоянии работы, когда что-то идет не так.

Git 2.17 (2 квартал 2018 г.) иллюстрирует это в коммите 3c93b82 (8 января 2018 г.), выполненном SZEDER Gábor ( szeder) .
^{(Объединено Junio ​​C Hamano - gitster- в коммите c710d18 , 8 марта 2018 г.)}

Это иллюстрирует практическое различие между before_install, install, before_scriptи scriptвариантами

travis-ci: построить Git на scriptэтапе ' '

С тех пор, как мы начали сборку и тестирование Git на Travis CI ( 522354d : добавление поддержки Travis CI, 2015-11-27, Git v2.7.0-rc0), мы создаем Git на этапе ' before_script' и запускаем набор тестов в ' script' фаза (за исключением представленных позже 32-битных заданий сборки Linux и Windows, где мы строим на script«фазе»).

Напротив, практика Travis CI состоит в том, чтобы создавать и тестировать на этапе " script"; действительно, команда сборки Travis CI по умолчанию для scriptфазы проектов C / C ++:

./configure && make && make test

Причина, по которой Travis CI делает это таким образом и почему этот подход лучше, чем наш, заключается в том, как классифицируются неудачные задачи сборки. После того, как что-то пошло не так при сборке, его состояние может быть:

• 'не удалось' , если команда в scriptфазе ' ' вернула ошибку.
  На это указывает красный значок «X» в веб-интерфейсе Travis CI.

• 'errored' , если команда на фазе ' before_install', ' install' или ' before_script' вернула ошибку или задание сборки превысило лимит времени.
  Это отображается красным "!" в веб-интерфейсе.

Это упрощает как людям, просматривающим веб-интерфейс Travis CI, так и автоматизированным инструментам, запрашивающим Travis CI API, решение, когда неудачная сборка является нашей обязанностью, требующей внимания человека, то есть когда задание сборки «не удалось» из-за компилятора. ошибка или сбой теста, и когда это вызвано чем-то вне нашего контроля и может быть исправлено путем перезапуска задания сборки, например, когда задание сборки содержит ошибку, потому что зависимость не может быть установлена ​​из-за временной сетевой ошибки или из-за того, что Задание сборки OSX превысило отведенное время.

Недостатком сборки Git на этапе " before_script" является то, что нужно также проверять журнал трассировки всех заданий сборки с ошибками, чтобы узнать, что вызвало ошибку, поскольку она могла быть вызвана ошибкой компилятора.
Это требует дополнительных кликов и загрузок страниц в веб-интерфейсе, а также дополнительной сложности и запросов API в автоматизированных инструментах.

Поэтому переместите сборку Git из before_scriptфазы ' ' в фазу ' script', также обновив имя скрипта соответствующим образом.
' ci/run-builds.sh' теперь становится практически пустым, удалите его.
Некоторые из наших конфигураций заданий сборки отменяют наше значение по умолчанию: before_script«ничего не делать; с этим изменением наше значение по умолчанию before_scriptтоже ничего не сделает, так что удалите и эти переопределяющие директивы.