doc-locale/fr-fr/ci/inputs/_index.md
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Utilisez les entrées CI/CD pour augmenter la flexibilité de la configuration CI/CD. Les entrées et les variables CI/CD peuvent être utilisées de manière similaire, mais présentent des avantages différents :
rules pour une configuration de pipeline dynamique.Entrées :
.gitlab-ci.yml) et dont les valeurs sont assignées lorsqu'un pipeline est déclenché, permettant aux utilisateurs de personnaliser les configurations CI réutilisables..gitlab-ci.yml ou dans un fichier inclus avec included. Vous pouvez les transmettre explicitement à d'autres fichiers — en utilisant include:inputs — ou au pipeline en utilisant trigger:inputs.Variables CI/CD :
spec:inputs {#define-input-parameters-with-specinputs}Utilisez spec:inputs dans l'en-tête de configuration CI/CD pour définir les paramètres d'entrée qui peuvent être transmis au fichier de configuration.
Utilisez le format d'interpolation $[[ inputs.input-id ]] en dehors de la section d'en-tête pour déclarer où utiliser les entrées.
Par exemple :
spec:
inputs:
job-stage:
default: test
environment:
default: production
---
scan-website:
stage: $[[ inputs.job-stage ]]
script: ./scan-website $[[ inputs.environment ]]
Dans cet exemple, les entrées sont job-stage et environment.
Vous ne pouvez utiliser les valeurs d'entrée que dans le fichier comportant la section spec. Pour utiliser une valeur d'entrée provenant d'un fichier différent ajouté avec include, transmettez-la explicitement au fichier inclus.
Avec spec:inputs :
default n'est pas spécifié.include.spec:inputs contient également des définitions de job, ajoutez un séparateur de document YAML (---) après l'en-tête.Ensuite, vous définissez les valeurs des entrées lorsque vous :
include. Sinon, le pipeline pourrait ne pas démarrer si un nouveau pipeline se déclenche automatiquement, notamment dans :
include:inputs et sont utilisées à chaque fois que la configuration est incluse.Pour configurer les entrées, utilisez :
spec:inputs:default pour définir les valeurs par défaut des entrées lorsqu'elles ne sont pas spécifiées. Lorsque vous spécifiez une valeur par défaut, les entrées ne sont plus obligatoires.spec:inputs:description pour donner une description à une entrée spécifique. La description n'affecte pas l'entrée, mais peut aider les utilisateurs à comprendre les détails de l'entrée ou les valeurs attendues.spec:inputs:options pour spécifier une liste de valeurs autorisées pour une entrée.spec:inputs:regex pour spécifier une expression régulière à laquelle l'entrée doit correspondre.spec:inputs:type pour forcer un type d'entrée spécifique, qui peut être string (par défaut si non spécifié), array, number, ou boolean.spec:inputs:rules pour définir des valeurs options et default conditionnelles basées sur les valeurs d'autres entrées.Vous pouvez définir plusieurs entrées par fichier de configuration CI/CD, et chaque entrée peut avoir plusieurs paramètres de configuration.
Par exemple, dans un fichier nommé scan-website-job.yml :
spec:
inputs:
job-prefix: # Mandatory string input
description: "Define a prefix for the job name"
job-stage: # Optional string input with a default value when not provided
default: test
environment: # Mandatory input that must match one of the options
options: ['test', 'staging', 'production']
concurrency:
type: number # Optional numeric input with a default value when not provided
default: 1
version: # Mandatory string input that must match the regular expression
type: string
regex: ^v\d\.\d+(\.\d+)$
export_results: # Optional boolean input with a default value when not provided
type: boolean
default: true
---
"$[[ inputs.job-prefix ]]-scan-website":
stage: $[[ inputs.job-stage ]]
script:
- echo "scanning website -e $[[ inputs.environment ]] -c $[[ inputs.concurrency ]] -v $[[ inputs.version ]]"
- if $[[ inputs.export_results ]]; then echo "export results"; fi
Dans cet exemple :
job-prefix est une entrée de type chaîne obligatoire et doit être définie.job-stage est facultatif. Si non défini, la valeur est test.environment est une entrée de type chaîne obligatoire qui doit correspondre à l'une des options définies.concurrency est une entrée numérique facultative. Si non spécifié, la valeur par défaut est 1.version est une entrée de type chaîne obligatoire qui doit correspondre à l'expression régulière spécifiée.export_results est une entrée booléenne facultative. Si non spécifié, la valeur par défaut est true.Vous pouvez spécifier qu'une entrée doit utiliser un type spécifique avec le mot-clé facultatif spec:inputs:type.
Les types d'entrée sont :
arraybooleannumberstring (par défaut si non spécifié)Lorsqu'une entrée remplace une valeur YAML entière dans la configuration CI/CD, elle est interpolée dans la configuration selon son type spécifié. Par exemple :
spec:
inputs:
array_input:
type: array
boolean_input:
type: boolean
number_input:
type: number
string_input:
type: string
---
test_job:
allow_failure: $[[ inputs.boolean_input ]]
needs: $[[ inputs.array_input ]]
parallel: $[[ inputs.number_input ]]
script: $[[ inputs.string_input ]]
Lorsqu'une entrée est insérée dans une valeur YAML dans le cadre d'une chaîne plus longue, l'entrée est toujours interpolée en tant que chaîne. Par exemple :
spec:
inputs:
port:
type: number
---
test_job:
script: curl "https://gitlab.com:$[[ inputs.port ]]"
{{< history >}}
{{< /history >}}
Le contenu des éléments d'un type tableau peut être n'importe quelle carte YAML valide, séquence ou scalaire. Les fonctionnalités YAML plus complexes comme !reference ne peuvent pas être utilisées. Lors de l'utilisation de la valeur d'une entrée de type tableau dans une chaîne (par exemple echo "My rules: $[[ inputs.rules-config ]]" dans votre section script:), vous pourriez obtenir des résultats inattendus. L'entrée de type tableau est convertie en sa représentation sous forme de chaîne, qui pourrait ne pas correspondre à vos attentes pour des structures YAML complexes telles que les cartes.
spec:
inputs:
rules-config:
type: array
default:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: manual
- if: $CI_PIPELINE_SOURCE == "schedule"
---
test_job:
rules: $[[ inputs.rules-config ]]
script: ls
Les entrées de type tableau doivent être formatées en JSON, par exemple ["array-input-1", "array-input-2"], lors de la transmission manuelle d'entrées pour :
{{< history >}}
{{< /history >}}
Vous pouvez définir une liste d'options pour restreindre les valeurs autorisées pour les entrées de type tableau. Lorsque vous exécutez un pipeline manuellement, l'interface utilisateur affiche une liste déroulante à sélection multiple au lieu d'un champ de texte. Par exemple :
spec:
inputs:
runner_tags:
type: array
default: ["docker"]
options:
- docker
- linux
- gpu
- macos
---
test:
script:
- run_tests.sh
tags: $[[ inputs.runner_tags ]]
Le pipeline ne démarre pas si une valeur de l'entrée de type tableau ne correspond pas à une option listée.
{{< history >}}
ci_inputs_array_index_operator. Désactivé par défaut.ci_inputs_array_index_operator supprimé.{{< /history >}}
Utilisez la notation entre crochets avec un numéro d'index pour accéder aux éléments individuels d'une entrée de type tableau. Les éléments du tableau sont indexés dans l'ordre où ils sont définis dans le tableau YAML, avec des nombres positifs, et l'élément d'index [0] est le premier élément du tableau.
Par exemple :
spec:
inputs:
supported_versions:
type: array
default:
- '2.0'
- '1.0'
- '0.1'
---
job:
script:
# Outputs: 'Latest version is 2.0'
- echo 'Latest version is $[[ inputs.supported_versions[0] ]]'
Vous pouvez chaîner l'indexation de tableau avec la notation par points pour accéder aux valeurs imbriquées :
spec:
inputs:
servers:
type: array
default:
- host: server1.example.com
port: 8080
---
job:
script:
- curl "https://$[[ inputs.servers[0].host ]]:$[[ inputs.servers[0].port ]]"
Pour les tableaux multidimensionnels, utilisez plusieurs indices à la suite. Par exemple, vous pouvez utiliser [0][1] pour un tableau à 2 dimensions :
spec:
inputs:
matrix:
type: array
default:
- ['a', 'b']
- ['c', 'd']
---
job:
script:
# Outputs: 'b'
- echo $[[ inputs.matrix[0][1] ]]
Vous pouvez chaîner un maximum de 5 indices par segment, par exemple arr[0][1][2][3][4].
Les entrées prennent en charge différents types de valeurs. Vous pouvez transmettre des valeurs de chaînes multiples en utilisant le format suivant :
spec:
inputs:
closed_message:
description: Message to announce when an issue is closed.
default: 'Hi {{author}} :wave:,
Based on the policy for inactive issues, this is now being closed.
If this issue requires further attention, reopen this issue.'
---
spec:inputs:rules {#define-conditional-input-options-with-specinputsrules}{{< history >}}
{{< /history >}}
Utilisez spec:inputs:rules pour définir différentes valeurs options et default pour une entrée en fonction des valeurs d'autres entrées. Vous pouvez utiliser cette configuration lorsqu'une entrée doit avoir différentes valeurs autorisées selon le contexte fourni par d'autres entrées.
Chaque règle dans la liste rules peut avoir :
if : Une expression qui vérifie les valeurs d'une ou plusieurs entrées pour déterminer quand cette règle s'applique. Utilise la même syntaxe que l'interpolation $[[ inputs.input-id ]].options : Une liste de valeurs autorisées pour l'entrée lorsque cette règle correspond.default : La valeur par défaut à utiliser lorsque cette règle correspond.Les règles sont évaluées dans l'ordre. La première règle avec une condition if correspondante est utilisée. La dernière règle sans condition if agit comme solution de repli lorsqu'aucune autre règle ne correspond.
Par exemple, pour définir des types d'instances qui varient selon le fournisseur cloud et l'environnement :
spec:
inputs:
cloud_provider:
options: ['aws', 'gcp', 'azure']
default: 'aws'
description: 'Cloud provider'
environment:
options: ['development', 'staging', 'production']
default: 'development'
description: 'Target environment'
instance_type:
description: 'VM instance type'
rules:
- if: $[[ inputs.cloud_provider ]] == 'aws' && $[[ inputs.environment ]] == 'development'
options: ['t3.micro', 't3.small']
default: 't3.micro'
- if: $[[ inputs.cloud_provider ]] == 'aws' && $[[ inputs.environment ]] == 'production'
options: ['t3.xlarge', 't3.2xlarge', 'm5.xlarge']
default: 't3.xlarge'
- if: $[[ inputs.cloud_provider ]] == 'gcp'
options: ['e2-micro', 'e2-small', 'e2-standard-4']
default: 'e2-micro'
- if: $[[ inputs.cloud_provider ]] == 'azure'
options: ['Standard_B1s', 'Standard_B2s', 'Standard_D2s_v3']
default: 'Standard_B1s'
- options: ['small', 'medium', 'large'] # Fallback for any other case
default: 'small'
---
deploy:
script: |
echo "Deploying to $[[ inputs.cloud_provider ]]"
echo "Environment: $[[ inputs.environment ]]"
echo "Instance: $[[ inputs.instance_type ]]"
Dans cet exemple :
cloud_provider est aws et environment est development, l'utilisateur peut sélectionner parmi les types d'instances t3.micro ou t3.small, avec t3.micro comme valeur par défaut.cloud_provider est aws et environment est production, différents types d'instances sont disponibles (t3.xlarge, t3.2xlarge, m5.xlarge).cloud_provider est gcp, les types d'instances spécifiques à GCP sont disponibles quel que soit l'environnement.Vous pouvez également utiliser l'opérateur || (OR) pour faire correspondre plusieurs conditions. Par exemple :
spec:
inputs:
deployment_type:
options: ['canary', 'blue-green', 'rolling', 'recreate']
default: 'rolling'
requires_approval:
description: 'Whether deployment requires manual approval'
rules:
- if: $[[ inputs.deployment_type ]] == 'canary' || $[[ inputs.deployment_type ]] == 'blue-green'
options: ['true']
default: 'true'
- options: ['true', 'false']
default: 'false'
---
deploy:
script: echo "Deploying with $[[ inputs.deployment_type ]] strategy"
Dans cet exemple, l'entrée requires_approval est définie sur true lorsque deployment_type est soit canary soit blue-green. Dans tous les autres cas, la valeur par défaut est false et true ou false sont tous les deux des options autorisées.
default: null {#allow-user-entered-values-with-default-null}{{< history >}}
{{< /history >}}
Utilisez spec:inputs:rules avec default: null et sans options pour permettre aux utilisateurs de saisir leur propre valeur pour une entrée. Ceci est utile pour les valeurs spécifiques au flux de travail, comme les noms d'environnements ou les configurations de test.
Par exemple :
spec:
inputs:
deployment_type:
options: ['standard', 'custom']
default: 'standard'
custom_config:
description: 'Custom configuration value'
rules:
- if: $[[ inputs.deployment_type ]] == 'custom'
default: null
---
deploy:
script: echo "Config: $[[ inputs.custom_config ]]"
Dans cet exemple, lorsque deployment_type est custom, l'entrée custom_config est répertoriée sur la page d'exécution du pipeline et les utilisateurs doivent saisir une valeur pour l'entrée.
spec:inputs:rules {#use-boolean-inputs-with-specinputsrules}Vous pouvez utiliser des entrées booléennes dans les conditions de règle. Les valeurs booléennes peuvent être comparées à l'aide de littéraux booléens (true/false) :
spec:
inputs:
publish:
type: boolean
default: true
publish_stage:
rules:
- if: $[[ inputs.publish ]] == true
default: 'publish'
- if: $[[ inputs.publish ]] == false
default: 'test'
---
job:
stage: $[[ inputs.publish_stage ]]
script: echo "Publishing is $[[ inputs.publish ]]"
Dans cet exemple, lorsque publish est true, publish_stage prend par défaut la valeur publish. Lorsque publish est false, la valeur par défaut est test.
Vous pouvez définir les valeurs d'entrée dans la configuration de votre pipeline ou lors du déclenchement d'un pipeline.
Une fois le pipeline démarré, vous ne pouvez pas récupérer les valeurs d'entrée utilisées. Si une valeur est sûre à exposer, vous pouvez l'afficher dans un job log pour référence future, ou la sauvegarder dans un artefact.
include {#for-configuration-added-with-include}{{< history >}}
include:with renommé en include:inputs dans GitLab 16.0.{{< /history >}}
Utilisez include:inputs pour définir les valeurs des entrées lorsque la configuration incluse est ajoutée au pipeline, notamment pour :
include.Par exemple, pour inclure et définir les valeurs d'entrée pour scan-website-job.yml à partir de l'exemple de configuration d'entrée :
include:
- local: 'scan-website-job.yml'
inputs:
job-prefix: 'some-service-'
environment: 'staging'
concurrency: 2
version: 'v1.3.2'
export_results: false
Dans cet exemple, les entrées pour la configuration incluse sont :
| Entrée | Valeur | Détails |
|---|---|---|
job-prefix | some-service- | Doit être explicitement défini. |
job-stage | test | Non défini dans include:inputs, donc la valeur provient de spec:inputs:default dans la configuration incluse. |
environment | staging | Doit être explicitement défini et doit correspondre à l'une des valeurs dans spec:inputs:options de la configuration incluse. |
concurrency | 2 | Doit être une valeur numérique pour correspondre au spec:inputs:type défini sur number dans la configuration incluse. Remplace la valeur par défaut. |
version | v1.3.2 | Doit être explicitement défini et doit correspondre à l'expression régulière dans spec:inputs:regex de la configuration incluse. |
export_results | false | Doit être soit true soit false pour correspondre au spec:inputs:type défini sur boolean dans la configuration incluse. Remplace la valeur par défaut. |
Les valeurs d'entrée sont uniquement disponibles dans le même fichier que la section spec qui les définit. Un fichier ajouté avec include ne peut pas accéder aux entrées définies dans d'autres fichiers, ni dans le fichier qui l'inclut. Pour utiliser une valeur d'un fichier inclus, transmettez-la explicitement avec include:inputs.
include {#with-multiple-include-entries}Les entrées doivent être spécifiées séparément pour chaque entrée include. Par exemple :
include:
- component: $CI_SERVER_FQDN/the-namespace/the-project/[email protected]
inputs:
stage: my-stage
- local: path/to/file.yml
inputs:
stage: my-stage
{{< history >}}
{{< /history >}}
Les entrées offrent des avantages par rapport aux variables, notamment la vérification des types, la validation et un contrat clair. Les entrées inattendues sont rejetées. Les entrées pour les pipelines doivent être définies dans l'en-tête spec:inputs du fichier principal .gitlab-ci.yml. Vous ne pouvez pas utiliser des entrées définies dans des fichiers inclus pour la configuration au niveau du pipeline.
[!note] Dans GitLab 17.7 et versions ultérieures, les entrées de pipeline sont recommandées plutôt que la transmission de variables de pipeline. Pour une sécurité renforcée, vous devriez désactiver les variables de pipeline lors de l'utilisation d'entrées.
Vous devriez toujours définir des valeurs par défaut lors de la définition des entrées pour les pipelines. Si une entrée n'a pas de valeur par défaut, le pipeline échoue lorsqu'il se déclenche automatiquement. Par exemple, les pipelines de pipeline de merge request peuvent se déclencher pour des modifications apportées à la branche source d'une merge request. Vous ne pouvez pas définir manuellement des entrées pour les pipelines de merge request, donc si une entrée n'a pas de valeur par défaut, le pipeline échoue. Cela peut également se produire pour les pipelines de branche, les pipelines de tag et les autres pipelines déclenchés automatiquement.
Vous pouvez définir les valeurs d'entrée avec :
triggerUn pipeline peut accepter jusqu'à 20 entrées.
Les retours sont les bienvenus sur ce ticket.
Vous pouvez transmettre des entrées aux pipelines downstream, si le fichier de configuration du pipeline downstream utilise spec:inputs.
Par exemple, avec trigger:inputs :
{{< tabs >}}
{{< tab title="Pipeline parent-enfant" >}}
trigger-job:
trigger:
strategy: mirror
include:
- local: path/to/child-pipeline.yml
inputs:
job-name: "defined"
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
{{< /tab >}}
{{< tab title="Pipeline multi-projets" >}}
trigger-job:
trigger:
strategy: mirror
project: project-group/my-downstream-project
inputs:
job-name: "defined"
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
{{< /tab >}}
{{< /tabs >}}
{{< history >}}
ci_file_inputs. Désactivé par défaut.ci_file_inputs supprimé.{{< /history >}}
Vous pouvez réutiliser les définitions d'entrée de pipeline dans plusieurs configurations CI/CD en les définissant dans des fichiers externes et en les incluant dans la configuration de pipeline d'un projet avec spec:include.
Créez un fichier avec des définitions d'entrée, par exemple dans un fichier nommé shared-inputs.yml :
inputs:
environment:
description: "Deployment environment"
options: ['staging', 'production']
region:
default: 'us-east-1'
Vous pouvez ensuite inclure les entrées externes dans votre .gitlab-ci.yml avec local :
spec:
include:
- local: /shared-inputs.yml
---
deploy:
script: echo "Deploying to $[[ inputs.environment ]] in $[[ inputs.region ]]"
Si le fichier est stocké en dehors de votre projet, vous pouvez utiliser :
project pour les fichiers dans un autre projet GitLab. Utilisez le chemin complet du projet et définissez le nom de fichier avec file. Vous pouvez également définir la ref à partir de laquelle récupérer le fichier.remote pour les fichiers sur un autre serveur. Utilisez l'URL complète vers le fichier.Vous pouvez également inclure plusieurs fichiers d'entrée en même temps, par exemple :
spec:
include:
- local: /shared-inputs.yml
- project: 'my-group/shared-configs'
ref: main
file: '/ci/common-inputs.yml'
- remote: 'https://example.com/ci/shared-inputs.yml'
---
[!note] Vous ne pouvez pas utiliser
spec:includepour les entrées de composant CI/CD.
{{< history >}}
{{< /history >}}
Les clés d'entrée doivent être uniques dans tous les fichiers inclus et les spécifications en ligne. Si vous définissez une entrée avec la même clé dans plusieurs fichiers inclus, ou à la fois dans un fichier inclus et la section inputs: dans la configuration .gitlab-ci.yml, l'erreur suivante est retournée :
Duplicate input keys found: environment. Input keys must be unique across all included files and inline specifications.
Pour corriger cette erreur, assurez-vous que chaque clé d'entrée est définie une seule fois, soit dans un fichier inclus, soit dans la section inputs: en ligne, mais pas les deux.
{{< history >}}
{{< /history >}}
Vous pouvez spécifier des fonctions prédéfinies dans le bloc d'interpolation pour manipuler la valeur d'entrée. Le format pris en charge est le suivant :
$[[ input.input-id | <function1> | <function2> | ... <functionN> ]]
Avec les fonctions :
spec:
inputs:
test:
default: 'test $MY_VAR'
---
test-job:
script: echo $[[ inputs.test | expand_vars | truncate(5,8) ]]
Dans cet exemple, en supposant que l'entrée utilise la valeur par défaut et que $MY_VAR est une variable de projet non masquée avec la valeur my value :
expand_vars développe la valeur en test my value.truncate s'applique à test my value avec un décalage de caractères de 5 et une longueur de 8.script serait echo my value.expand_vars {#expand_vars}{{< history >}}
{{< /history >}}
Utilisez expand_vars pour développer les variables CI/CD dans la valeur d'entrée.
Seules les variables que vous pouvez utiliser avec le mot-clé include et qui ne sont pas masquées peuvent être développées. L'expansion de variables imbriquées n'est pas prise en charge.
Exemple :
spec:
inputs:
test:
default: 'test $MY_VAR'
---
test-job:
script: echo $[[ inputs.test | expand_vars ]]
Dans cet exemple, si $MY_VAR n'est pas masquée (exposée dans les job logs) avec une valeur de my value, alors l'entrée se développerait en test my value.
truncate {#truncate}{{< history >}}
{{< /history >}}
Utilisez truncate pour raccourcir la valeur interpolée. Par exemple :
truncate(<offset>,<length>)| Nom | Type | Description |
|---|---|---|
offset | Entier | Nombre de caractères de décalage. |
length | Entier | Nombre de caractères à retourner après le décalage. |
Exemple :
$[[ inputs.test | truncate(3,5) ]]
En supposant que la valeur de inputs.test est 0123456789, la sortie serait 34567.
posix_escape {#posix_escape}{{< history >}}
{{< /history >}}
Utilisez posix_escape pour échapper les caractères de contrôle ou métacaractères Bourne shell POSIX dans les valeurs d'entrée. posix_escape échappe les caractères en insérant \ avant les caractères concernés dans l'entrée.
Exemple :
spec:
inputs:
test:
default: |
A string with single ' and double " quotes and blanks
---
test-job:
script: printf '%s\n' $[[ inputs.test | posix_escape ]]
Dans cet exemple, posix_escape échappe les caractères qui pourraient être des caractères de contrôle shell ou des métacaractères :
$ printf '%s\n' A\ string\ with\ single\ \'\ and\ double\ \"\ quotes\ and\ \ \ blanks
A string with single ' and double " quotes and blanks
L'entrée échappée préserve les caractères spéciaux et l'espacement tels que fournis.
[!warning] Ne pas utiliser
posix_escapeà des fins de sécurité avec des valeurs d'entrée non fiables.
posix_escape tente du mieux possible de préserver exactement la valeur d'entrée, mais certaines combinaisons de caractères peuvent toujours provoquer des résultats indésirables. Même lors de l'utilisation de posix_escape, il est possible que :
Pour des raisons de sécurité, vous devriez vous assurer que vos entrées sont fiables. Vous pouvez utiliser :
spec:input:type number ou boolean, qui ne peuvent pas contenir de caractères problématiques.spec:input:regex pour empêcher les entrées problématiques.spec:input:options pour définir une liste prédéfinie d'options d'entrée.Si vous combinez posix_escape avec expand_vars, vous devez d'abord définir expand_vars. Sinon, posix_escape échapperait le $ dans la variable, empêchant l'expansion. Par exemple :
test-job:
script: echo $[[ inputs.test | expand_vars | posix_escape ]]
inputs dans rules {#yaml-syntax-errors-when-using-inputs-in-rules}Lorsque vous utilisez une entrée pour modifier des expressions rules:if, vous pourriez obtenir l'une des nombreuses erreurs de syntaxe.
Ces erreurs sont souvent liées à la façon dont les chaînes sont gérées dans les expressions de variables CI/CD. Les expressions dans rules:if attendent une variable CI/CD comparée à une chaîne entre guillemets (' ou ") ou à une autre variable. Lorsque les valeurs d'entrée sont insérées dans la configuration rules lors de l'exécution du pipeline, la valeur résultante pourrait ne pas être une chaîne entre guillemets ou une variable, ce qui provoque l'erreur.
Par exemple, dans la configuration à inclure :
spec:
inputs:
branch:
default: $CI_DEFAULT_BRANCH
branch2:
default: $CI_DEFAULT_BRANCH
---
job-name:
rules:
- if: $CI_COMMIT_REF_NAME == $[[ inputs.branch ]]
- if: $CI_COMMIT_REF_NAME == $[[ inputs.branch2 ]]
Ensuite, dans le fichier de configuration principal :
include:
inputs:
branch: $CI_DEFAULT_BRANCH # Valid
branch2: main # Invalid
Dans cet exemple :
branch: $CI_DEFAULT_BRANCH est valide. La clause if: évalue à if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH, ce qui est une expression de variable valide. La variable n'a pas besoin d'être entre guillemets.branch2: main est invalide. La clause if: évalue à if: $CI_COMMIT_REF_NAME == main, ce qui est invalide car main est une chaîne mais n'est pas entre guillemets.Pour résoudre ce problème, assurez-vous que les expressions restent correctement formatées après l'insertion des valeurs d'entrée dans la configuration. Cela peut nécessiter des guillemets supplémentaires. Par exemple, ajoutez des guillemets aux règles qui utilisent des valeurs de type chaîne :
rules:
if: $CI_COMMIT_REF_NAME == "$[[ inputs.branch2 ]]"
Pour les fonctions d'interpolation comme expand_vars, vous pourriez également avoir besoin de mettre entre guillemets l'expression if: entière. Par exemple :
spec:
inputs:
environment:
default: "$ENVIRONMENT"
---
$[[ inputs.environment | expand_vars ]] job:
script: echo
rules:
- if: '"$[[ inputs.environment | expand_vars ]]" == "production"'
Dans cet exemple, mettre entre guillemets à la fois l'entrée et l'expression if: entière garantit une syntaxe valide après l'évaluation de l'entrée. Lorsque les guillemets sont imbriqués, utilisez " pour les guillemets internes et ' pour les guillemets externes, ou l'inverse.
Les noms de job n'ont pas besoin d'être entre guillemets.