Dans un job CI on peut cacher un fichier ou des dossiers résultant d'une commande, afin de le récupérer lors d'un prochain job.
Le dossier à cacher pourrait-être par exemple le dossier vendor lors d'un composer install afin que le prochain job ne relance pas cette commande inutilement.
Mais pour être encore plus efficace, il est possible de mettre comme clé de cache le fichier composer.lock lié. Ainsi, si le fichier composer.lock évolue, alors gitlab-ci saura que le dossier caché vendor n'est plus d'actualité.
Voici comment faire ça :
build:app:
cache:
key:
files:
- composer.lock
paths:
- vendor/
script:
- composer install --no-dev
Comme vous le devinez peut-être, il est possible de cacher plusieurs dossiers (via la clé paths) et de déterminer la validité du cache en fonction de plusieurs fichiers (via la clé key.files)
Pour plus d'informations sur gitlab et le cache : https://docs.gitlab.com/ee/ci/caching/
Contenus en rapport
J’utilise énormément la partie « CI » de Gitlab pour déployer automatiquement les sites et applications web que je gère.
Pour un projet, j'ai du mettre en place une stratégie de déploiement automatisée avec entre autres un déploiement sur un serveur de préproduction que lors de la création d'un tag preprod-x.x exemples : preprod-0.1, preprod-0.2, preprod-1.0...
.gitlab-ci.yml
stages :
- predeploy
- deploy
- postdeploy
- scheduled
prod_backup_db:
script:
- ssh <a href="mailto:user@serveur">user@serveur</a> 'drush @kg cr'
- ssh <a href="mailto:u
Ajouter un commentaire