Options avancées pour la construction automatique et le test automatique

Table des matières

Note

Les constructions automatiques nécessitent un abonnement Docker Pro, Team ou Business.

Les options suivantes permettent de personnaliser vos processus de construction automatique et de test automatique.

Variables d'environnement pour la construction et le test

Plusieurs variables d'environnement utilitaires sont définies par le processus de construction et sont disponibles lors des constructions automatiques, des tests automatiques et lors de l'exécution des hooks.

Note

Ces variables d'environnement ne sont disponibles que pour les processus de construction et de test et n'affectent pas l'environnement d'exécution de votre service.

SOURCE_BRANCH: le nom de la branche ou de l'étiquette qui est actuellement testée.
SOURCE_COMMIT: le hash SHA1 du commit testé.
COMMIT_MSG: le message du commit testé et construit.
DOCKER_REPO: le nom du dépôt Docker construit.
DOCKERFILE_PATH: le dockerfile actuellement construit.
DOCKER_TAG: l'étiquette du dépôt Docker construite.
IMAGE_NAME: le nom et l'étiquette du dépôt Docker construit. (Cette variable est une combinaison de DOCKER_REPO:DOCKER_TAG.)

Si vous utilisez ces variables d'environnement de construction dans un fichier docker-compose.test.yml pour les tests automatiques, déclarez-les dans l'environnement de votre service sut comme indiqué ci-dessous.

services:
  sut:
    build: .
    command: run_tests.sh
    environment:
      - SOURCE_BRANCH

Remplacer les commandes de construction, test ou push

Docker Hub vous permet de remplacer et personnaliser les commandes build, test et push lors des processus de construction automatique et de test en utilisant des hooks. Par exemple, vous pourriez utiliser un hook de construction pour définir des arguments de construction utilisés uniquement pendant le processus de construction. Vous pouvez également configurer des hooks de phase de construction personnalisés pour effectuer des actions entre ces commandes.

Important

Utilisez ces hooks avec précaution. Le contenu de ces fichiers de hook remplace les commandes docker de base, vous devez donc inclure une commande de construction, test ou push similaire dans le hook ou votre processus automatique ne se terminera pas.

Pour remplacer ces phases, créez un dossier appelé hooks dans votre dépôt de code source au même niveau de répertoire que votre Dockerfile. Créez un fichier appelé hooks/build, hooks/test, ou hooks/push et incluez des commandes que le processus de construction peut exécuter, telles que des commandes docker et bash (préfixées de manière appropriée avec #!/bin/bash).

Ces hooks s'exécutent sur une instance d'Ubuntu, qui inclut des interpréteurs tels que Perl ou Python, et des utilitaires tels que git ou curl. Consultez la documentation Ubuntu pour la liste complète des interpréteurs et utilitaires disponibles.

Hooks de phase de construction personnalisés

Vous pouvez exécuter des commandes personnalisées entre les phases du processus de construction en créant des hooks. Les hooks vous permettent de fournir des instructions supplémentaires aux processus de construction automatique et de test automatique.

Créez un dossier appelé hooks dans votre dépôt de code source au même niveau de répertoire que votre Dockerfile. Placez les fichiers qui définissent les hooks dans ce dossier. Les fichiers de hook peuvent inclure à la fois des commandes docker et des commandes bash tant qu'elles sont préfixées de manière appropriée avec #!/bin/bash. Le constructeur exécute les commandes dans les fichiers avant et après chaque étape.

Les hooks suivants sont disponibles :

hooks/post_checkout
hooks/pre_build
hooks/post_build
hooks/pre_test
hooks/post_test
hooks/pre_push (utilisé uniquement lors de l'exécution d'une règle de construction ou Construction automatique )
hooks/post_push (utilisé uniquement lors de l'exécution d'une règle de construction ou Construction automatique )

Exemples de hooks de construction

Remplacer la phase "construction" pour définir des variables

Docker Hub vous permet de définir des variables d'environnement de construction soit dans les fichiers de hook, soit depuis l'interface de construction automatique, que vous pouvez ensuite référencer dans les hooks.

L'exemple suivant définit un hook de construction qui utilise des arguments docker build pour définir la variable CUSTOM basée sur la valeur d'une variable définie en utilisant les paramètres de construction Docker Hub. $DOCKERFILE_PATH est une variable que vous fournissez avec le nom du Dockerfile que vous voulez construire, et $IMAGE_NAME est le nom de l'image construite.

$ docker build --build-arg CUSTOM=$VAR -f $DOCKERFILE_PATH -t $IMAGE_NAME .

Important

Un fichier hooks/build remplace la commande docker build de base utilisée par le constructeur, vous devez donc inclure une commande de construction similaire dans le hook ou la construction automatique échouera.

Consultez la documentation docker build pour en apprendre plus sur les variables de construction Docker.

Pousser vers plusieurs dépôts

Par défaut, le processus de construction pousse l'image uniquement vers le dépôt où les paramètres de construction sont configurés. Si vous devez pousser la même image vers plusieurs dépôts, vous pouvez configurer un hook post_push pour ajouter des étiquettes supplémentaires et pousser vers plus de dépôts.

$ docker tag $IMAGE_NAME $DOCKER_REPO:$SOURCE_COMMIT
$ docker push $DOCKER_REPO:$SOURCE_COMMIT

Clones de dépôt source ou de branche

Lorsque Docker Hub tire une branche d'un dépôt de code source, il effectue un clone superficiel, il clone uniquement le bout de la branche spécifiée. Cela a l'avantage de minimiser la quantité de transfert de données nécessaire depuis le dépôt et d'accélérer la construction car il tire uniquement le code minimal nécessaire.

En conséquence, si vous devez effectuer une action personnalisée qui dépend d'une branche différente, telle qu'un hook post_push, vous ne pouvez pas faire un checkout de cette branche à moins de faire l'une des choses suivantes :

Vous pouvez obtenir un checkout superficiel de la branche cible en faisant ce qui suit :
$ git fetch origin branch:mytargetbranch --depth 1
Vous pouvez également "dés-superficialiser" le clone, qui récupère tout l'historique Git (et potentiellement prend beaucoup de temps / déplace beaucoup de données) en utilisant le drapeau --unshallow sur le fetch :
$ git fetch --unshallow origin