Assez souvent chez webofmars et build-and-run nous intervenons pour mettre en place des CI/CD dans différentes startups et grand comptes. Une des choses que personnellement je trouve perfectible avec ce travail c’est que vous vous retrouvez dans la situation suivante :
- Vous créer une branche
- Vous faites une modification dans votre fichier de CI/CD (le plus souvent en YAML)
- Vous commitez votre modification
- Vous poussez vers la branche distante
- Le pipeline se déclenche
- Vous allez boire un café … et puis un autre …………
- Ah zut il manque la commande tar pour décompresser l’archive. C’est dommage ;-)
C’est un mode de fonctionnement “try (and pray) and catch ». Mais attendez ce n’est pas ce que l’on essaie justement de ne pas subir avec le DevOps ? Avant nous restions devant des setups d’Ubuntu maintenant devant des pipelines Gitlab … Il doit avoir une meilleure voie !
Notre solution chez webofmars
Avec le temps nous en sommes arrivés au setup suivant qui nous permet de faire tourner les jobs gitlab en local sur nos environnements de dev avant de les pousser vers les dépôts distants :
les pré-requis
- dotenv
- docker
- gitlab-runner installé (vous pouvez suivre cette documentation)
- un bon éditeur de code
le mode opératoire
La mise en place de cette astuce ne nécessite au final pas beaucoup de temps ni de ressources. C’est très pratique pour valider vos steps de CI avant de jouer complètement tout le worflow. Il ya toutefois quelques limitations à connaitre:
- Vous êtes limités aux ressources disponibles dans votre environment docker local (VM sous windows et macos)
- Un seul step à la fois, on ne peut donc pas faire tourner le workflow au complet
- Pas de gestion des artefacts et des dépendances
- Cache peu efficace
Créer un fichier .env
Peut être en avez vous déjà un dans votre code vu que cela est en train de devenir un standard, si c’est le cas ajoutez juste quelques variables, sinon créer en un nouveau.``` SSH_PRIVATE_KEY=“xxxxxxxxx - redacted base64 content — xxxxxxxxx” AWS_DEFAULT_REGION=“eu-west-3” AWS_ACCESS_KEY_ID=“redacted” AWS_SECRET_ACCESS_KEY=“redacted”
### Créer un fichier .local-ci
Il vous faut maintenant créer le corps de notre CI/CD locale via un simple script shell comme ci-dessous:```
#!/bin/bash
CI\_STEP="${1:-build}"
echo "+ running gitlab-runner"
gitlab-runner exec docker \\
--docker-privileged \\
--env CI\_PIPELINE\_ID="0000" \\
--env CI\_COMMIT\_SHA1="$(git rev-parse --short HEAD)" \\
--env CI\_COMMIT\_TAG="local-ci" \\
--env SSH\_PRIVATE\_KEY="$(echo ${SSH\_PRIVATE\_KEY} | base64 --decode)" \\
--env AWS\_DEFAULT\_REGION="${AWS\_DEFAULT\_REGION}" \\
--env AWS\_ACCESS\_KEY\_ID="${AWS\_ACCESS\_KEY\_ID}" \\
--env AWS\_SECRET\_ACCESS\_KEY="${AWS\_SECRET\_ACCESS\_KEY}" \\
--cache-dir=/tmp/gitlab-cache \\
--docker-cache-dir=/tmp/gitlab-cache \\
--docker-volumes=/tmp/gitlab-cache \\
"${CI\_STEP}"
Utilisez le !
Et voilà ! A chaque fois que vous voudrez tester vos modifications sur un un job de CI via le .gitlab-ci.yaml il vous suffira d’appeler la commande suivante dans votre répertoire de votre projet: bash .local-ci. Enjoy :-) Pour référence tous le code source est situé sur github