doc-locale/fr-fr/ci/inputs/examples.md
{{< details >}}
{{< /details >}}
Les entrées CI/CD augmentent la flexibilité de votre configuration CI/CD. Utilisez ces exemples comme guide pour configurer votre pipeline avec des entrées.
Vous pouvez inclure le même fichier plusieurs fois, avec différentes entrées. Cependant, si plusieurs jobs portant le même nom sont ajoutés à un pipeline, chaque job supplémentaire écrase le job précédent portant le même nom. Vous devez vous assurer que la configuration empêche les noms de jobs en double.
Par exemple, en incluant la même configuration plusieurs fois avec différentes entrées :
include:
- local: path/to/my-super-linter.yml
inputs:
linter: docs
lint-path: "doc/"
- local: path/to/my-super-linter.yml
inputs:
linter: yaml
lint-path: "data/yaml/"
La configuration dans path/to/my-super-linter.yml garantit que le job a un nom unique à chaque fois qu'il est inclus :
spec:
inputs:
linter:
lint-path:
---
"run-$[[ inputs.linter ]]-lint":
script: ./lint --$[[ inputs.linter ]] --path=$[[ inputs.lint-path ]]
inputs {#reuse-configuration-in-inputs}Pour réutiliser la configuration avec inputs, vous pouvez utiliser les ancres YAML.
Par exemple, pour réutiliser la même configuration rules avec plusieurs composants CI/CD qui prennent en charge les tableaux rules dans les entrées :
.my-job-rules: &my-job-rules
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
include:
- component: $CI_SERVER_FQDN/project/path/component1@main
inputs:
job-rules: *my-job-rules
- component: $CI_SERVER_FQDN/project/path/component2@main
inputs:
job-rules: *my-job-rules
Vous ne pouvez pas utiliser les balises !reference dans les entrées, mais le ticket 424481 propose l'ajout de cette fonctionnalité.
inputs avec needs {#use-inputs-with-needs}Vous pouvez utiliser des entrées de type tableau avec needs pour des dépendances de jobs complexes.
Par exemple, dans un fichier nommé component.yml :
spec:
inputs:
first_needs:
type: array
second_needs:
type: array
---
test_job:
script: echo "this job has needs"
needs:
- $[[ inputs.first_needs ]]
- $[[ inputs.second_needs ]]
Dans cet exemple, les entrées sont first_needs et second_needs, toutes deux des entrées de type tableau. Ensuite, dans un fichier .gitlab-ci.yml, vous pouvez ajouter cette configuration et définir les valeurs des entrées :
include:
- local: 'component.yml'
inputs:
first_needs:
- build1
second_needs:
- build2
Lorsque le pipeline démarre, les éléments du tableau needs pour test_job sont concaténés en :
test_job:
script: echo "this job has needs"
needs:
- build1
- build2
needs lors de l'inclusion {#allow-needs-to-be-expanded-when-included}Vous pouvez avoir needs dans un job inclus, mais aussi ajouter des jobs supplémentaires au tableau needs avec spec:inputs.
Par exemple :
spec:
inputs:
test_job_needs:
type: array
default: []
---
build-job:
script:
- echo "My build job"
test-job:
script:
- echo "My test job"
needs:
- build-job
- $[[ inputs.test_job_needs ]]
Dans cet exemple :
test-job a toujours besoin de build-job.test_job_needs: est vide par défaut.Pour que test-job nécessite un autre job dans votre configuration, ajoutez-le à l'entrée test_needs lorsque vous incluez le fichier. Par exemple :
include:
- component: $CI_SERVER_FQDN/project/path/[email protected]
inputs:
test_job_needs: [my-other-job]
my-other-job:
script:
- echo "I want build-job` in the component to need this job too"
needs à un job inclus qui n'a pas de needs {#add-needs-to-an-included-job-that-doesnt-have-needs}Vous pouvez ajouter needs à un job inclus qui n'a pas encore needs de défini. Par exemple, dans la configuration d'un composant CI/CD :
spec:
inputs:
test_job:
default: test-job
---
build-job:
script:
- echo "My build job"
"$[[ inputs.test_job ]]":
script:
- echo "My test job"
Dans cet exemple, la section spec:inputs permet de personnaliser le nom du job.
Ensuite, après avoir inclus le composant CI/CD, vous pouvez étendre le job avec la configuration needs supplémentaire. Par exemple :
include:
- component: $CI_SERVER_FQDN/project/path/[email protected]
inputs:
test_job: my-test-job
my-test-job:
needs: [my-other-job]
my-other-job:
script:
- echo "I want `my-test-job` to need this job"
inputs avec include pour des pipelines plus dynamiques {#use-inputs-with-include-for-more-dynamic-pipelines}Vous pouvez utiliser inputs avec include pour sélectionner les fichiers de configuration de pipeline supplémentaires à inclure.
Par exemple :
spec:
inputs:
pipeline-type:
type: string
default: development
options: ['development', 'canary', 'production']
description: "The pipeline type, which determines which set of jobs to include."
---
include:
- local: .gitlab/ci/$[[ inputs.pipeline-type ]].gitlab-ci.yml
Dans cet exemple, le fichier .gitlab/ci/development.gitlab-ci.yml est inclus par défaut. Mais si une option d'entrée pipeline-type différente est utilisée, un fichier de configuration différent est inclus.
Vous pouvez utiliser les entrées CI/CD pour personnaliser les expressions de variables. Par exemple :
example-job:
script: echo "Testing"
rules:
- if: '"$[[ inputs.some_example ]]" == "test-branch"'
L'expression est évaluée en deux étapes :
Interpolation des entrées : Avant la création du pipeline, les entrées sont remplacées par la valeur d'entrée. Dans cet exemple, l'entrée $[[ inputs.some_example ]] est remplacée par la valeur définie. Par exemple, si la valeur est :
test-branch, l'expression devient if: '"test-branch" == "test-branch"'.$CI_COMMIT_BRANCH, l'expression devient if: '"$CI_COMMIT_BRANCH" == "test-branch"'.Évaluation de l'expression : Une fois les entrées interpolées, GitLab tente de créer le pipeline. Lors de la création du pipeline, les expressions sont évaluées pour déterminer quels jobs ajouter au pipeline.