Gitlab-ci est l’un des outils qui nous est le plus utile. C’est l’équivalent de Travis-CI pour les projets Github.

En deux mots, cet outil permet de lancer automatiquement une série de commandes (en général des test et des déploiement) dès qu’une branche est pushée ou qu’une Merge Request est ouverte sur Gitlab.

Nous utilisons Gitlab-ci pour tous nos projets web, quellle que soit la technologie. Voici comment nous l’utilisons pour les composants PHP.

Make et commandes du build

La majorité de nos projets utilisent Make comme outil d’ordonnancement de tâches. Make est un outil comme Gulp, Grunt, Phing, Ant… À ceci près que Make existe depuis 40, est très mature, et ne sera pas passé de mode dans 6 mois. Cela ne nous empêche pas, bien entendu, d’utiliser Gulp ou Grunt lorsqu’ils répondent à un cas d’usage précis.

Pour fonctionner, Make lit un fichier Makefile, qui définie un certain nombre de cibles:

# Fichier Makefile
tache1:
	@echo "hello"

tache2: tache1 
	@echo "world"

tache2 est dépendant de tache1. La commande make tache2 affichera dans le terminal “hello\nworld”. Nous utilisons un arobase (@) afin de ne pas afficher dans le terminal la commande qui est exécutée.

Notez que l’indentation se fait par une vraie tabulation ; sans quoi Make ne fonctionnera pas.

Voici par exemple le fichier Makefile de notre framework PHP commun:

# Fichier Makefile
.PHONY: build install test lint checkstyle ci-tag

build:
	@wget -nc http://get.sensiolabs.org/sami.phar && chmod +x sami.phar
	@mkdir -p build
	@php sami.phar update .sami.php
	@php phpmetrics.phar --report-html=build/phpmetrics --report-violations=build/violations.xml Rf

install:
	@wget -nc https://getcomposer.org/composer.phar
	@php -dmemory_limit=4G composer.phar install --prefer-dist
	@wget -nc https://squizlabs.github.io/PHP_CodeSniffer/phpcs.phar
	@wget -nc https://github.com/phpmetrics/PhpMetrics/releases/download/v2.0.0-rc/phpmetrics.phar

test: lint checkstyle
	@./vendor/bin/phpunit

ci: install lint checkstyle
	@./vendor/bin/phpunit --coverage-text --colors=never

lint:
	@find Rf -name "*.php" -print0 | xargs -0 -n1 -P8 php -l > /dev/null
checkstyle:
	@php phpcs.phar --standard=PSR1,PSR2 Rf

tag:
	./tag.sh

Nous avons ainsi une liste de commandes utiles:

  • build pour sera lancée par Jenkins lors du build. Cette commande génère la phpdoc et les rapports de code.
  • install télécharge et installe nos dépendances.
  • test (qui dépend de lint et checkstyle est lancé par l’intégration continue pour lancer nos tests unitaires, contrôler la syntaxe des fichiers PHP et vérifier que nous respectons nos conventions de codage.
  • tag lance un script bash pour indenter nos tag Git.
  • ci est la commande qui sert de point d’entrée à l’intégration continue.

Le fichier Gitlab-ci

Pour fonctionner, Gitlab-ci va lire le contenu du fichier .gitlab-ci.yml présent à la racine de notre dépôt. Ce fichier décrit les instructions que Gitlab-ci doit suivre lorsqu’une Pull Request est ouverte sur le dépôt :

# Fichier Makefile
test:php56:
   image: registry.dnm.radiofrance.fr/php:5.6
   script:
    - make ci

test:php70:
   image: registry.dnm.radiofrance.fr/php:7.0
   script:
    - make ci

Ce fichier décrit deux cibles de test. Les tests sont lancés dans deux conteneurs Docker ; l’un pour PHP 7, l’autre pour PHP 5.6

Nous utilisons notre propre registry Docker. Ces images ne sont pas donc pas référencées sur le Hub Docker officiel.

Activation dans Gitlab

Il faut s’assurer que les builds sont bien activés dans la configuration du projet (la case à cocher Buildsdoit être cochée) :

Configuration du gitlab

Note: il vous faudra un Runner Gitlab actif (tel que décrit dans la documentation officielle).

Désormais les tests sont exécutés à chaque Merge Request. Vous obtenez la résultats des tests à côté du bouton “Merge” (voire il n’est plus possible de merger si les tests ne passent pas, selon la configuration de votre projet) :

Configuration du gitlab

Conclusion

Bien que très utile, Gitlab-ci n’est pas totalement suffisant. Il ne permet pas (sans passer par des rustines) par exemple de créer des matrices de test, comme on pourrait le faire avec Travis-ci. C’est pour cela que nous utilisons Jenkins pour créer des matrices pour nous assurer que nos Bundles symfony restent compatibles avec toutes les versions de Symfony que nous utilisons.

Ceci dit, vu la vitesse d’évolution de Gitlab, il est probable que ce point soit corrigé bientôt. Gitlab-ci reste aujourd’hui un moyen extrêmement simple de faire de l’intégration continue de vos projets PHP si vous utilisez Gitlab.