Configuration dans .pipeline-config.yaml

Utilisez un fichier de configuration .pipeline-config.yaml pour étendre les fonctionnalités du pipeline.

Emplacement de fichier

Pour les pull requests et les pipelines d'intégration continue, stockez le fichier de configuration .pipeline-config.yaml dans un référentiel d'application .travis.yml, de la même manière que les Jenkinsfile fichiers ou. Pour les pipelines de déploiement continu, enregistrez ce fichier dans un référentiel dédié.

Pour tous les pipelines, vous pouvez personnaliser l'emplacement et la source du fichier .pipeline-config.yaml à l'aide des paramètres de l'interface utilisateur de pipeline suivants :

• pipeline-config, pour définir le chemin d'accès au fichier de configuration. La valeur par défaut est .pipeline-config.yaml.
• pipeline-config-repo pour définir le référentiel à partir duquel extraire la configuration et les scripts. La valeur par défaut est le référentiel d'applications d'intégration continue.
• pipeline-config-branch À utiliser comme branche pour la configuration dans le référentiel de configuration. La valeur par défaut correspond à la branche du référentiel de l'application en intégration continue, et à la branche master en déploiement continu.

Paramètres de configuration

La configuration dans le fichier .pipeline-config.yaml prend en charge les paramètres suivants :

Il ne s'agit pas de paramètres de pipeline ; ils doivent faire partie de votre fichier .pipeline-config.yaml.

• image : vous pouvez utiliser n'importe quelle image Docker accessible par le noeud worker de pipeline comme image de base pour la tâche.

• script : script d'exécution dans l'étape. Ce champ étant utilisé comme fichier de script, assurez-vous que son contenu se comporte comme un fichier de script dans l’image de base que vous avez fournie. Vous pouvez inclure d'autres scripts en regard de ce fichier de configuration et y faire référence à partir de ce point d'entrée. Exemple :

test:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  script: |
    #!/bin/sh
    scripts/lint.sh
    scripts/unit-test.sh

• dind : spécifiez s'il convient d'activer ou non docker-in-docker dans le contexte de script. Le paramétrage par défaut est false.

• abort_on_failure : par défaut, le pipeline s'arrête lorsque le script échoue. La définition de cette valeur sur false marque l'étape dans un avertissement (état ambre) (passé avec avertissement), permet au pipeline de continuer et le travail ayant échoué est référencé dans les informations collectées.

• image_pull_policy: Définissez le paramètre ImagePullPolicy de pod fourni dans l'image pour l'image de base. Les valeurs possibles sont les mêmes que les valeurs valides pour Kubernetes : Always ou IfNotPresent. La valeur par défaut est IfNotPresent.

• configmap : extrayez des paires clé-valeur d'une mappe de configuration fournie qui est accessible par PipelineRun. Les valeurs suivantes sont prises en charge :

  • config-name : syntaxe de nom de mappe de configuration directe. Le module d'exécution de l'étape tente d'accéder à la mappe de configuration config-name et de la monter.
  • $prop-name : syntaxe de nom de mappe de configuration indirecte. Le nom de mappe de configuration est recherché dans la mappe de configuration environment-properties, qui contient chaque valeur d'environnement définie sur l'interface utilisateur de pipeline. Par exemple, s'il existe une my-config entrée prop dans les propriétés de l'environnement, alors my-config est utilisé pour $prop.

• secret : extrayez des paires clé-valeur d'une mappe de configuration fournie qui est accessible par PipelineRun. Les valeurs suivantes sont prises en charge :

  • secret-name : syntaxe de nom de secret directe. Le module d'exécution de l'étape tente d'accéder au secret secret-name et de le monter.

  • $prop-name : syntaxe de nom de secret indirecte. Le nom Secret se trouve dans la carte de configuration environment-properties qui contient toutes les valeurs d'environnement définies dans l'interface utilisateur du pipeline. Par exemple, si la mappe de configuration environment-properties contient la propriété my-secret, my-secret est utilisé pour $prop.

• runAfter: Exécutez l'étape en cours une fois l'étape spécifiée dans cette propriété terminée. Définissez la valeur avec le nom d'étape que vous avez utilisé dans .pipeline-config.yaml. Utilisez cette propriété avec parcimonie et confirmez que l'étape spécifiée par cette propriété existe dans le pipeline. Si l'étape n'existe pas, le pipeline peut entrer dans un interblocage.

• skip: si la valeur est true, ignorez l'étape en cours, si possible, dans les pipelines v10. Toutes les étapes ne peuvent pas être ignorées. Le tableau suivant répertorie les étapes qui peuvent être ignorées lors de l'exécution du pipeline.

version: '1' # fixed, this value is used to track schema changes
# `setup` runs right after the app repo is cloned
setup:
  # the pipeline will break in case setup fails (default is true)
  abort_on_failure: true
  # any docker image can be used which is accessible by the private worker
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  # you can reference configmaps, each key in the configmap is going to be available as `/config/{key}`
  configmap: my-config
    # `$prop` is the indirect config map syntax, the concrete configmap is looked
    # up from the `environment-properties` configmap
    #
    # Eg. if there's a `prop: my-config` entry in the environment properties,
    # then `my-config` is going to be used for `$prop`
  configmap: $prop
  # the mechanism described works for secrets as well!
  secret: $my-secrets
  # the script is executed inside the checked out app repo
  script: |
    #!/bin/sh
    ...
# `test` runs after `setup`, but before building the docker image
test:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  script: |
    #!/bin/sh
    ...
# `static-scan` runs after `test`, but before building the docker image
static-scan:
  image: ibmcom/pipeline-base-image:2.12
  script: |
    #!/bin/sh
    ...
# `deploy` runs after building the docker image
deploy:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  # the script has access to the built docker image, which is available at `/config/image`
  script: |
    #!/bin/sh
    cat /config/image
# `dynamic-scan` runs after `deploy`, but before the acceptance test run
dynamic-scan:
  image: ibmcom/pipeline-base-image:2.12
  script: |
    #!/bin/sh
    ...
# `acceptance-test` runs after `deploy`
acceptance-test:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-image:2.69
  script: |
    #!/bin/sh
    ...