¿Cuáles son las diferencias entre las opciones {before _,} {install, script} .travis.yml?

Dentro del .travis.ymlarchivo de configuración de lo que es la diferencia práctica entre before_install, install, before_scripty scriptopciones?

No he encontrado documentación que explique las diferencias entre estas opciones.

No es necesario que utilice estas secciones, pero si lo hace, comunica la intención de lo que está haciendo:

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

Consulte, por ejemplo, https://github.com/localheinz/composer-normalize/blob/0.8.0/.travis.yml .

La diferencia está en el estado del trabajo cuando algo sale mal.

Git 2.17 (Q2 2018) ilustra que en el compromiso 3c93b82 (08 de enero de 2018) por SZEDER Gábor ( szeder) .
^{(Combinado por Junio ​​C Hamano - gitster- en commit c710d18 , 08 de marzo de 2018)}

Que ilustra la diferencia práctica entre before_install, install, before_scripty scriptopciones

travis-ci: compila Git durante la scriptfase ' '

Desde que comenzamos a construir y probar Git en Travis CI ( 522354d : agregar soporte de Travis CI, 2015-11-27, Git v2.7.0-rc0), compilamos Git en la ' before_script' fase y ejecutamos el conjunto de pruebas en el ' script' fase (excepto en los trabajos de compilación de Linux y Windows de 32 bits introducidos más tarde, donde compilamos en la script"fase").

Por el contrario, la práctica de Travis CI es construir y probar en la scriptfase " "; de hecho, el comando de compilación predeterminado de Travis CI para la scriptfase ' ' de los proyectos C / C ++ es:

./configure && make && make test

La razón por la que Travis CI lo hace de esta manera y por qué es un enfoque mejor que el nuestro radica en cómo se categorizan los trabajos de construcción fallidos. Después de que algo salió mal en un trabajo de construcción, su estado puede ser:

• 'falló' , si un comando en la scriptfase ' ' devolvió un error.
  Esto se indica con una 'X' roja en la interfaz web de Travis CI.

• 'errored' , si un comando en la fase ' before_install', ' install' o ' before_script' devolvió un error, o si el trabajo de compilación excedió el límite de tiempo.
  Esto se muestra como un '!' Rojo en la interfaz web.

Esto hace que sea más fácil, tanto para los humanos que miran la interfaz web de Travis CI como para las herramientas automatizadas que consultan la API de Travis CI, decidir cuándo una compilación fallida es nuestra responsabilidad que requiere atención humana, es decir, cuando un trabajo de compilación 'falló' debido a un compilador error o una falla en la prueba, y cuando es causado por algo más allá de nuestro control y podría solucionarse reiniciando el trabajo de compilación, por ejemplo, cuando un trabajo de compilación 'falló' porque una dependencia no se pudo instalar debido a un error de red temporal o porque el El trabajo de compilación de OSX superó su límite de tiempo.

El inconveniente de compilar Git en la before_scriptfase " " es que también hay que comprobar el registro de seguimiento de todos los trabajos de compilación "con errores" para ver qué causó el error, ya que podría haber sido causado por un error del compilador.
Esto requiere clics adicionales y cargas de página en la interfaz web y complejidad adicional y solicitudes de API en herramientas automatizadas.

Por lo tanto, mueva la construcción de Git de la " before_scriptfase" a la scriptfase " ", actualizando también el nombre del script en consecuencia.
' ci/run-builds.sh' ahora se vuelve básicamente vacío, elimínelo.
Varias de nuestras configuraciones de trabajo de compilación anulan nuestro ' before_script' predeterminado para no hacer nada; con este cambio, nuestro ' before_script' predeterminado tampoco hará nada, así que elimine también esas directivas primordiales.