Які відмінності між параметрами {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 (Q2 2018) ілюструє це у коміті 3c93b82 (08 січня 2018) від SZEDER Gábor ( szeder) .
^{(Об’єднано Junio ​​C Hamano - gitster- у коміті c710d18 , 08 березня 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` фазі '').

Навпаки, практика Тревіса CI полягає у побудові та випробуванні у scriptфазі ' '; дійсно командою збірки Travis CI за замовчуванням для scriptфази ' ' проектів C / C ++ є:

./configure && make && make test

Причина, чому Тревіс Сі робить це саме таким чином, і чому це кращий підхід, ніж наш, полягає в тому, як класифікуються невдалі робочі місця. Після того, як щось пішло не так у роботі зі збірки, її стан може бути таким:

• "не вдалося" , якщо команда на scriptетапі " " повернула помилку.
  Це позначається червоним знаком «X» на веб-інтерфейсі Travis CI.

• 'помилка' , якщо команда у фазі ' before_install', ' install' або ' before_script' повертає помилку, або завдання збірки перевищує обмеження часу.
  Це показано червоним знаком "!" на веб-інтерфейсі.

Це полегшує як людям, які переглядають веб-інтерфейс Travis CI, так і автоматизованим інструментам, що запитують API Travis CI, вирішити, коли невдала збірка - це наша відповідальність, що вимагає уваги людини, тобто коли робота збірки „не вдалася” через компілятор помилка або помилка тесту, а також коли вона викликана чимось поза нашим контролем і може бути виправлена ​​перезапуском завдання збірки, наприклад, коли завдання збірки `` помилилося '', оскільки залежність не вдалося встановити через тимчасову помилку мережі або через те, що Завдання збірки OSX перевищило обмеження за часом.

Недоліком побудови Git на before_scriptфазі ' ' є те, що потрібно також перевірити журнал трасування всіх `` помилкових '' завдань збірки, щоб побачити, що спричинило помилку, оскільки це могло бути спричинено помилкою компілятора.
Це вимагає додаткових кліків та завантаження сторінок у веб-інтерфейсі та додаткової складності та запитів API в автоматизованих інструментах.

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