Gitlab CI/CD

L'outil de forge logicielle open-source Gitlab (que vous connaissez déjà) propose un service d'intégration continue : Gitlab CI/CD.

Cet outil nous permet de :

• Créer et attacher des runners à des projets et des groupes
• Configurer des tâches à exécuter en réaction à des évènements Git

Schéma de fonctionnement

Configurer l'intégration continue

Pour commencer à utiliser Gitlab CI/CD dans votre projet, il faut configurer les tâches à effectuer dans un fichier nommé .gitlab-ci.yml, à placer à la racine de votre projet.

On nomme un ensemble de tâches, réparties par étapes et exécutées par des runners une pipeline. Depuis l'interface de Gitlab, vous pouvez accéder aux pipelines de votre projet depuis le menu à gauche, section CI/CD > Pipelines.

Pour définir une pipeline, il convient d'en définir les grandes étapes, nommées stages. Pour ce faire, on doit déclarer une liste stages dans notre fichier de configuration :

# Pour l'exemple uniquement
stages:
    - build
    - test
    - deploy

Ces grandes étapes sont composées de tâches, ou jobs, qui peuvent être exécutées simultanément. Les stages et jobs sont présentés dans l'interface de Gitlab comme ceci :

info

Dans notre cas, le PHP est un langage non compilé, et nous n'avons pas de traitement particulier à effectuer sur les fichiers pour pouvoir faire fonctionner l'application, nous n'avons donc pas besoin de phase de build. Typiquement, cette phase pourrait servir à transpiler un projet React par exemple.

Il nous faut maintenant remplir nos stages avec des jobs. Pour définir un job, il suffit d'ajouter à notre fichier un objet YAML dont la clé sera le nom du job. Une fois ceci fait, de nombreuses options de configuration s'offrent à nous. En voici quelques-unes des plus courantes :

• image : l'image Docker à utiliser pour effectuer cette tâche
• stage : l'étape dans laquelle se situe cette tâche
• before_script : un script à exécuter avant de commencer la tâche
• script : le script principal de la tâche, c'est son code de retour qui détermine le succès ou l'échec de la tâche.
• only : un objet qui permet de limiter les contextes dans lesquels le job est exécuté, par exemple : seulement sur la branche main.
• services : cet objet permet de configurer des conteneurs annexes à faire tourner en même temps que le job. Pratique pour lancer une base de données par exemple.
• variables : cet objet permet de configurer des variables pour notre tâche, qui seront passées comme variables d'environnement pour le script. Sachez également que les variables peuvent être déclarées depuis l'interface de Gitlab.

Exercice

Créez un fichier .gitlab-ci.yml à la racine de votre projet, définissez un job de test qui liste les fichiers du répertoire courant : ls -l. Faites un commit et envoyez-le sur votre repertoire Gitlab. Observez ensuite le résultat en passant par la section pipelines de votre projet. Comme vous pouvez le constater, quand le job s'exécute sur le runner, il dispose des sources de votre répertoire Git.

Mettre en place l'intégration continue

Maintenant que vous connaissez les bases de la configuration de pipelines avec Gitlab, créez un stage test, et remplissez-le avec les tests que vous avez étudiés dans les sections précédentes.

Correction

Correction

.gitlab-ci.yml

.php-tests-common: &php-tests-common
  stage: test
  image: jakzal/phpqa:php8.3-alpine
  before_script:
    - composer install
  cache:
    paths:
      - vendor/

default:
  tags:
    - lpmiaw

stages:
  - test

security-checker:
  <<: *php-tests-common
  script:
    - local-php-security-checker  --path=./composer.lock

phpcs:
  <<: *php-tests-common
  script:
    - phpcs -v --standard=PSR12 --ignore=./src/Kernel.php ./src

phpstan:
  <<: *php-tests-common
  script:
    - composer global bin phpstan remove phpstan/extension-installer
    - phpstan analyse ./src --level 3

twig-lint:
  <<: *php-tests-common
  script:
    - twig-lint lint ./templates

phpunit:
  image: nicolasunivlr/php:lp2024
  stage: test
  services:
    - name: mariadb:10.11
      alias: mariadb
  variables:
    MYSQL_ROOT_PASSWORD: root
    MYSQL_DATABASE: myapptest
    DATABASE_URL: 'mysql://root:root@mariadb:3306/myapptest?serverVersion=10.6.7-MariaDB&charset=utf8'
  before_script:
    - composer install
    - php bin/console doctrine:database:drop --if-exists --force --env=test
    - php bin/console doctrine:database:create --env=test
    - php bin/console d:m:m --env=test --no-interaction
    - php bin/console d:f:l --env=test --no-interaction
  script:
    - php bin/phpunit