Aetheus Docs
EN FR
Application

Pipelines

Un pipeline est un document YAML dans votre dépôt. Cette page décrit ce que contient ce document ; la page d'installation par pipeline s'en sert pour déployer Aetheus lui-même.

Où vit la définition

Les définitions de pipelines sont lues depuis le dépôt, sous .pipeline/<slug>.yaml. Le backend relit le fichier depuis le dépôt canonique à chaque lancement : la définition présente sur la branche par défaut est donc toujours celle qui s'exécute. Modifier un pipeline depuis l'interface web réécrit le YAML dans le dépôt et le commite, ce qui implique de récupérer les modifications sur un clone local avant de pousser à la main.

Squelette

name: mon-application-deploy
trigger: manual

variables:
  APP_VERSION: "1.0.$(BUILD_PIPELINE_RUNNUMBER)"
  DEPLOY_ROOT: "/srv/mon-application"

stages:
  - name: Build
    os: linux
    steps:
      - name: Compiler
        checkout: true
        working_directory: "$(WORKSPACE)"
        timeout_seconds: 1800
        shell: |
          set -eu
          ./build.sh

  - name: Deploy
    os: linux
    depends_on:
      - Build
    steps:
      - name: Publier sur l'hôte
        shell: sh deploy/publish.sh

Étapes

Une étape est l'unité d'ordonnancement. Elle est distribuée en bloc à un agent éligible, et déclare ses besoins :

  • os : linux ou windows, utilisé pour sélectionner un agent ;
  • depends_on : une liste de noms d'étapes. Les étapes sans dépendance non satisfaite s'exécutent en parallèle ; cette liste est la seule chose qui les sérialise ;
  • group : un regroupement d'affichage dans la vue d'exécution, par exemple Deploy. Sans effet sur l'ordonnancement ;
  • artifacts : les chemins que cette étape publie une fois ses tâches réussies. Les étapes suivantes, et les exécutions ultérieures, les restaurent par leur nom ;
  • execution_role : contrainte de routage facultative quand les agents sont spécialisés.

Tâches

Les tâches d'une étape s'exécutent dans l'ordre, sur le même agent et dans le même espace de travail. Les champs courants sont :

ChampSignification
nameLibellé affiché dans la chronologie d'exécution et dans les journaux.
shellLe script à exécuter. Un bloc littéral garde lisibles les scripts multi-lignes.
checkoutÀ vrai, clone la révision source épinglée dans l'espace de travail avant l'exécution.
working_directoryOù s'exécuter, généralement "$(WORKSPACE)".
timeout_secondsBudget de la tâche. Le dépassement échoue la tâche au lieu de bloquer l'exécution.
continue_on_errorSignale l'échec en avertissement et poursuit, au lieu d'échouer l'exécution.
typeSélectionne une tâche native au lieu d'un script shell ; voir ci-dessous.

Types de tâches natifs

Certains travaux gagnent à être exprimés en tâche de premier ordre plutôt qu'en script : le backend comprend alors le résultat au lieu d'analyser du texte. Les types employés par les pipelines livrés dans le dépôt sont :

TypeRôle
releaseEnregistre une release pour cette exécution : version, changelog, et si elle est déployée.
restore-artifactsRestaure des artefacts publiés par une autre étape ou une autre exécution.
triggerLance un autre pipeline et, si demandé, l'attend. L'exécution fille apparaît imbriquée dans la chronologie du parent.
coverage, lint, complexityIngèrent un rapport pour en faire un résultat de premier ordre sur l'exécution et sur le projet.
scanner, analysis-gateLancent un scanner de sécurité ou de qualité, puis bloquent l'exécution quand les remontées franchissent un seuil.
smokeSonde une URL déployée et échoue l'étape si la réponse n'est pas celle attendue.

Paramètres d'exécution

Un pipeline peut demander des valeurs au lancement via un bloc parameters: de premier niveau. Chaque paramètre a un type parmi string, boolean ou choice, et une valeur par défaut pour qu'une exécution planifiée ou déclenchée par webhook dispose quand même d'une valeur.

parameters:
  - name: revision
    display_name: Révision consignée dans le journal de déploiement
    type: string
    default: scheduled
    required: false

Variables

Les valeurs sont substituées par $(NOM). Trois sources alimentent la substitution :

variables:
  APP_VERSION: "1.0.$(BUILD_PIPELINE_RUNNUMBER)"

variable_libraries:
  - mes-valeurs-publiques

vaults:
  - secrets-mon-application

Une bibliothèque de variables n'est visible que par un pipeline qui la liste ; rien n'est appliqué implicitement. Un coffre absent est un échec net à la résolution des variables, de sorte qu'une tâche ne reçoit jamais silencieusement un secret vide.

Parmi les variables intégrées : $(WORKSPACE), le répertoire de checkout, BUILD_SOURCEVERSION, la révision exacte épinglée par l'exécution, et BUILD_PIPELINE_RUNNUMBER, le compteur de build propre au pipeline.

Les numéros de version sont des compteurs de build

BUILD_PIPELINE_RUNNUMBER s'incrémente à chaque lancement du pipeline, échecs et annulations compris. Un pipeline dont la version est 1.1.$(BUILD_PIPELINE_RUNNUMBER) produira donc 1.1.57 à son 57e lancement. Si vous voulez une version sémantique, dérivez-la d'une étiquette, pas de ce compteur.

Modèles

Un pipeline peut étendre un modèle publié avec extends: <modèle>@<version> et ne fournir que ses propres paramètres. Les modèles sont versionnés et immuables : une version publiée ne peut pas être modifiée, adopter un changement signifie donc passer explicitement à la version suivante. C'est ce qui empêche un parc de pipelines de dériver à votre insu.

Pour aller plus loin