travis ci - tutorial - ¿Cuáles son las diferencias entre las opciones{before_,}{install, script}.travis.yml?

travis ci vs jenkins

Question

Dentro del archivo de configuración .travis.yml , ¿cuál es la diferencia práctica entre las before_install , install , before_script y script ?

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

Answer 1

El ciclo de vida de Build

Una compilación en Travis CI consta de dos pasos:

install : instalar cualquier dependencia script requerido: ejecutar el script de compilación Puede ejecutar comandos personalizados antes del paso de instalación ( before_install ) y antes ( before_script ) o después ( after_script ) del paso de script.

En un paso before_install , puede instalar dependencias adicionales requeridas por su proyecto, como paquetes de Ubuntu o servicios personalizados.

Lee más here

Answer 2

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

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

Eso ilustra la diferencia práctica entre before_install , install , before_script y las opciones de script

travis-ci : construye Git durante la fase '' script ''

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

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

./configure && make && make test

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

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

• ''errored'' , si un comando en la before_install '' before_install '', '' install '' o '' before_script '' devolvió un error, o 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 de prueba, y cuando es causada por algo que está fuera de nuestro control y puede solucionarse reiniciando el trabajo de compilación, por ejemplo, cuando un trabajo de compilación ''erró'' porque no se pudo instalar una dependencia debido a un error de red temporal o porque el El trabajo de compilación de OSX excedió su límite de tiempo.

El inconveniente de construir Git en la fase '' before_script '' es que uno tiene que verificar el registro de seguimiento de todos los trabajos de compilación ''con errores'', también, 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 creación de Git de la fase '' before_script '' a la fase '' script '', actualizando el nombre del script en consecuencia también.
'' 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 también elimine esas directivas primordiales.

Answer 3

No necesita usar 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

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