Value ◦ Fullstack ◦ Fan de musique et dévoreur de Pitch ◎ Pierre Marichez ◦ Responsable PHP M6 Web Lille ◦ 20 ans de PHP ◦ Spécialisé en PHP Cunéiforme
lancé par Gitlab CI variables: TEST_FILE_NAME: build_is_done.txt .script_template: capistrano: &capistrano_script | if [ ! -f $TEST_FILE_NAME ]; then echo "Please launch the build job in this pipeline to get an artifact."; exit 1; fi bundle install bundle exec cap $CI_ENVIRONMENT_NAME deploy tag=$CI_COMMIT_REF_NAME --trace populate_dependencies: &populate_dependencies_script | composer install --no-interaction --optimize-autoloader composer run-script post-install-dev --no-interaction touch $TEST_FILE_NAME
rattachés à un job après qu’il se termine avec succès. Exemple .artifact_template: &artifact_definition artifacts: name: "${CI_PROJECT_NAME}_${CI_COMMIT_REF_NAME}" paths: - . expire_in: 1 month
- Définition des containers - Makefile - Gestion des alias par environnement [dev] make install == [test] make install == [builds] make install == [recette] make install
des projets par variable d’environnement - Facilite la cohabitation des environnements de recette - /!\ La génération de la conf peut échouer - /!\ Il a ses propres confs nginx par défaut
à jour conf gitlab-runner ◎ Gestion multi-projets (api + front + service tiers) ◎ copier/coller dockerfiles : pourquoi ? C’est historique ;) ◎ Docker + windows => LENT ◎ Docker In Docker dans runner : NE PAS MONTER LE SOCKET DE LA VM ! ◎ Version docker en local vs gitlab vs les autres (env recette, dev, …) ◎ Job manuel peuvent toujours être lancés même si allow_failure: false