Intégration continue Gitlab : il est frais mon fichier généré ?

Comment vérifier qu’un fichier généré a été régénéré dans l’intégration continue ?

Que ça soit de la traduction (extraction des clés), des objets métiers issus de la base de données (« jooq quand tu nous tiens ») ou encore du lint (qui a oublié de lancer gofmt ?), nous avons tous les jours besoin de générer des fichiers. Pour ne pas oublier de le faire, il existe plusieurs manières. Mais une documentation qui l’explique ou un hook git en pre-commit, ne permettent pas de s’assurer qu’un développeur le fasse. Voici trois techniques simples qui permettront à votre intégration continue de vous indiquer un oubli.

La commande log les outputs

Il suffit d’exécuter :

stages:
    - precheck

precheck:ma_commande:
    stage: precheck
    script:
        - diff -u <(echo -n) <(VOTRE COMMANDE); [ $$? -eq 0 ]

Si votre commande écrit dans le « stdout », le job sera « fail ». Dans le cas contraire, il réussira puisqu’il n’y a aucune modification entre le code courant et le résultat de la commande.

En pratique

Voici un cas d’utilisation pour s’assurer que le développeur a bien appliqué un `gofmt` :

stages:
    - precheck

precheck:gofmt:
    stage: precheck
    script:
        - diff -u <(echo -n) <(gofmt -s -d ./src); [ $$? -eq 0 ]

La commande génère un fichier non commité

Le même joueur joue encore :

stages:
    - precheck

precheck:ma_commande:
    stage: precheck
    script:
        - diff NOUVEAU_FICHIER ANCIEN_FICHIER

En pratique

Voici un cas d’utilisation pour s’assurer que le développeur a bien appliqué un `i18nExtractor` d’angular :

stages:
    - precheck

precheck:translation:
    stage: precheck
    script:
        - npm run compileAll
        - npm run i18nExtractor
        - diff ./build/translation.xlf ./app/translations/translation.xlf

Vous allez me demander : mais pourquoi ne pas en profiter pour faire un `mv ./build/translation.xlf ./app/translations/translation.xlf` ? Simplement, nous considérons qu’un build d’intégration continue ne doit pas toucher notre code et encore moins commiter dans notre git, bien qu’une merge-request automatique pourrait être déclanchée 😉

La commande génère un fichier commité sans output

Imaginons que nous avons remplacer le script npm de ` »i18nExtractor »: « ng-xi18n »` par ` »i18nExtractor »: « ng-xi18n && mv ./build/translation.xlf ./app/translations/translation.xlf »`, notre précédent script répondra toujours qu’il n’y a pas de différences.

Git vient à notre secours :

stages:
    - precheck

precheck:ma_commande:
    stage: precheck
    script:
        - npm run compileAll
        - npm run i18nExtractor
        - git diff --exit-code

Ainsi, si la tâche « i18nExtrator » génère un fichier à commiter, l’intégration continue échoue.

Conclusion

Avec ces 3 exemples, vous avez de quoi vérifier que les développeurs de votre équipe n’oublient jamais de générer un fichier. Idéalement, vous aurez mis en place d’autres systèmes pour leur faciliter la vie (git hook, scripts, makefile…). Mais avec ces checks en intégration continue vous avez la certitude qu’ils sont bien appliqués.

Si vous avez la moindre question ou remarque, n’hésitez pas à réagir.