doc-locale/fr-fr/ci/components/_index.md
{{< details >}}
{{< /details >}}
{{< history >}}
ci_namespace_catalog_experimental. Désactivé par défaut.ci_namespace_catalog_experimental supprimé dans GitLab 16.3.{{< /history >}}
Un composant CI/CD est une unité de configuration de pipeline unique et réutilisable. Utilisez des composants pour créer une petite partie d'un pipeline plus grand, ou même pour composer une configuration de pipeline complète.
Un composant peut être configuré avec des paramètres d'entrée pour un comportement plus dynamique.
Les composants CI/CD sont similaires aux autres types de configuration ajoutés avec le mot-clé include, mais présentent plusieurs avantages :
Plutôt que de créer vos propres composants, vous pouvez également rechercher des composants publiés qui ont les fonctionnalités dont vous avez besoin dans le Catalogue CI/CD.
<i class="fa-youtube-play" aria-hidden="true"></i> Pour une introduction et des exemples pratiques, voir Efficient DevSecOps workflows with reusable CI/CD components.
<!-- Video published on 2024-01-22. DRI: Developer Relations, <https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/399> -->Pour les questions fréquentes et une assistance supplémentaire, consultez la FAQ : GitLab CI/CD Catalog (article de blog).
{{< history >}}
{{< /history >}}
Un projet de composant est un projet GitLab avec un dépôt qui héberge un ou plusieurs composants. Tous les composants du projet sont versionnés ensemble, avec un maximum de 30 composants par projet.
Si un composant nécessite un versionnage différent des autres composants, le composant doit être déplacé vers un projet de composant dédié.
Pour créer un projet de composant, vous devez :
Créer un nouveau projet avec un fichier README.md :
Les composants publiés dans le catalogue CI/CD utilisent à la fois la description et l'avatar lors de l'affichage du résumé du projet de composant.
Ajoutez un fichier de configuration YAML pour chaque composant, en suivant la structure de répertoire requise. Par exemple :
spec:
inputs:
stage:
default: test
---
component-job:
script: echo job 1
stage: $[[ inputs.stage ]]
Vous pouvez utiliser le composant immédiatement, mais vous souhaiterez peut-être envisager de publier le composant dans le catalogue CI/CD.
Le dépôt doit contenir :
README.md documentant les détails de tous les composants dans le dépôt.templates/ de niveau supérieur qui contient toutes les configurations de composants. Dans ce répertoire, vous pouvez :
.yml pour chaque composant, comme templates/secret-detection.yml.template.yml pour chaque composant, comme templates/secret-detection/template.yml. Seul le fichier template.yml est utilisé par d'autres projets utilisant le composant. Les autres fichiers dans ces répertoires ne sont pas publiés avec le composant, mais peuvent être utilisés pour des choses comme les tests ou la construction d'images de conteneur.[!note] Chaque composant peut également avoir son propre fichier
README.mdqui fournit des informations plus détaillées, et peut être lié depuis le fichierREADME.mdde niveau supérieur. Cela permet de fournir une meilleure vue d'ensemble de votre projet de composant et de son utilisation.
Vous devriez également :
.gitlab-ci.yml du projet pour tester les composants et publier de nouvelles versions.LICENSE.md avec une licence de votre choix qui couvre l'utilisation de votre composant. Par exemple les licences open source MIT ou Apache 2.0.Par exemple :
Si le projet contient un seul composant, la structure de répertoire doit être similaire à :
├── templates/
│ └── my-component.yml
├── LICENSE.md
├── README.md
└── .gitlab-ci.yml
Si le projet contient plusieurs composants, la structure de répertoire doit être similaire à :
├── templates/
│ ├── my-component.yml
│ └── my-other-component/
│ ├── template.yml
│ ├── Dockerfile
│ └── test.sh
├── LICENSE.md
├── README.md
└── .gitlab-ci.yml
Dans cet exemple :
my-component est définie dans un seul fichier.my-other-component contient plusieurs fichiers dans un répertoire. Seul le fichier template.yml peut être utilisé par d'autres projets utilisant le composant.Prérequis :
Si vous êtes membre d'un groupe parent qui contient le groupe ou le projet actuel :
Pour ajouter un composant à la configuration CI/CD d'un projet, utilisez le mot-clé include: component. La référence du composant est formatée comme <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version>, par exemple :
include:
- component: $CI_SERVER_FQDN/my-org/security-components/[email protected]
inputs:
stage: build
Dans cet exemple :
$CI_SERVER_FQDN est une variable prédéfinie pour le nom de domaine pleinement qualifié (FQDN) correspondant à l'hôte GitLab. Vous pouvez uniquement référencer des composants dans la même instance GitLab que votre projet.my-org/security-components est le chemin complet du projet contenant le composant.secret-detection est le nom du composant qui est défini soit comme un fichier unique templates/secret-detection.yml soit comme un répertoire templates/secret-detection/ contenant un template.yml.1.0.0 est la version du composant.La configuration du pipeline et la configuration du composant ne sont pas traitées indépendamment. Lorsqu'un pipeline démarre, toute configuration de composant incluse fusionne dans la configuration du pipeline. Si votre pipeline et le composant contiennent tous deux une configuration avec le même nom, ils peuvent interagir de manière inattendue.
Par exemple, deux jobs avec le même nom fusionneraient en un seul job. De même, un composant utilisant extends pour la configuration avec le même nom qu'un job dans votre pipeline pourrait étendre la mauvaise configuration. Assurez-vous que votre pipeline et le composant ne partagent aucune configuration avec le même nom, sauf si vous avez l'intention de remplacer la configuration du composant.
Pour utiliser des composants GitLab.com sur une instance GitLab Self-Managed, vous devez mettre en miroir le projet de composant.
[!warning] Si un composant nécessite l'utilisation de jetons, de mots de passe ou d'autres données sensibles pour fonctionner, assurez-vous d'auditer le code source du composant afin de vérifier que les données ne sont utilisées que pour effectuer des actions que vous attendez et autorisez. Vous devez également utiliser des jetons et des secrets avec les permissions minimales, l'accès ou la portée requis pour effectuer l'action.
Par ordre de priorité décroissante, la version du composant peut être :
e3262fdd0914fa823210cdb79a8c421e2cef79d8.1.0.0. Si un tag et un SHA de commit existent avec le même nom, le SHA de commit est prioritaire sur le tag. Les composants publiés dans le Catalogue CI/CD doivent être taggés avec une version sémantique.main. Si une branche et un tag existent avec le même nom, le tag est prioritaire sur la branche.~latest ou une version sémantique partielle, qui sélectionne la dernière version dans le modèle spécifié publié dans le Catalogue CI/CD. Utilisez ~latest uniquement si vous souhaitez utiliser la toute dernière version en permanence, ce qui pourrait inclure des modifications avec rupture. ~latest n'inclut pas les pré-versions, par exemple 1.0.1-rc, qui ne sont pas considérées comme prêtes pour la production.Vous pouvez utiliser n'importe quelle version prise en charge par le composant, mais l'utilisation d'une version publiée dans le catalogue CI/CD est recommandée. La version référencée avec un SHA de commit ou un nom de branche peut ne pas être publiée dans le catalogue CI/CD, mais pourrait être utilisée à des fins de test.
{{< history >}}
{{< /history >}}
Vous pouvez utiliser des numéros de version sémantique partiels et le mot-clé ~latest lors du référencement d'un composant CI/CD de catalogue pour sélectionner la dernière version publiée correspondant à votre spécification.
Ces formats ne fonctionnent qu'avec des composants CI/CD de catalogue publiés, pas avec des composants de projet ordinaires. Cela garantit que lorsque vous utilisez des formats tels que 1.2 ou ~latest, vous ne récupérez que des composants qui ont été validés et publiés dans le catalogue, plutôt que du code potentiellement non testé provenant de n'importe quel dépôt.
Cette approche offre des avantages significatifs tant pour les utilisateurs que pour les auteurs de composants :
Utilisez :
1.2 pour sélectionner la dernière version 1.2.*1 pour sélectionner la dernière version 1.*.*~latest pour sélectionner la dernière version publiéePar exemple, un composant a les versions : 1.0.0, 1.1.0, 1.1.1, 1.2.0, 2.0.0, 2.0.1, 2.1.0
Lors du référencement du composant :
1 sélectionne 1.2.01.1 sélectionne 1.1.1~latest sélectionne 2.1.0Les versions pré-release ne sont jamais récupérées lors de l'utilisation de la sélection de version partielle. Pour récupérer une version pré-release, spécifiez la version complète, par exemple 1.0.1-rc.
{{< history >}}
ci_component_context_interpolation. Activé par défaut.ci_component_context_interpolation supprimé.{{< /history >}}
Les composants peuvent accéder à leurs propres métadonnées grâce à une expression CI/CD de contexte de composant. Utilisez cette expression dans les templates de composants pour référencer la version, le SHA de commit et d'autres métadonnées de manière dynamique.
Pour utiliser le contexte de composant dans un composant, vous devez :
spec:component. spec:component prend en charge les champs name, sha, version et reference.$[[ component.field-name ]] dans le template de composant.Par exemple, un composant qui référence une image Docker construite avec la même version :
spec:
component: [name, version, reference]
inputs:
stage:
default: build
---
build-image:
stage: $[[ inputs.stage ]]
image: registry.example.com/$[[ component.name ]]:$[[ component.version ]]
script:
- echo "Building with component version $[[ component.version ]]"
- echo "Component reference: $[[ component.reference ]]"
Vous pouvez également utiliser le contexte de composant pour référencer des ressources versionnées.
spec du composant {#component-spec-section}La section spec dans un template de composant définit la configuration et les entrées du composant. Vous pouvez utiliser les mots-clés suivants dans la section spec :
description : Fournissez une courte description du composant qui est affichée dans le Catalogue CI/CD.inputs : Définissez des paramètres d'entrée pour que les utilisateurs puissent personnaliser la configuration du composant.component : Déclarez les champs de contexte de composant à rendre disponibles pour l'interpolation (comme name, sha, version et reference).[!note] Vous ne pouvez pas utiliser
spec:includedans les composants. Les composants doivent être autonomes et ne pas dépendre de fichiers externes. Définissez les entrées directement dans le composant au lieu de les inclure depuis des fichiers séparés.
Cette section décrit quelques bonnes pratiques pour créer des projets de composants de haute qualité.
Bien qu'il soit possible pour un composant d'utiliser d'autres composants à son tour, assurez-vous de sélectionner soigneusement les dépendances. Pour gérer les dépendances, vous devez :
include:local est un bon moyen de s'assurer que le même SHA Git est utilisé dans plusieurs fichiers.~latest ou une référence Git. L'utilisation d'une release ou d'un SHA Git garantit que vous récupérez toujours la même révision et que les utilisateurs de votre composant obtiennent un comportement cohérent.README.md clair {#write-a-clear-readmemd}Chaque projet de composant doit avoir une documentation claire et complète. Pour rédiger un bon fichier README.md :
## Components avec des sous-sections comme ### Component A pour chaque composant.spec:inputs:description pour documenter toutes les variables ou tous les secrets utilisés par le composant.README. Les entrées apparaissent automatiquement sur la page du composant. À la place, créez un lien vers le composant publié.## Contribute si les contributions sont les bienvenues.Si un composant nécessite plus d'instructions, ajoutez de la documentation supplémentaire dans un fichier Markdown dans le répertoire du composant et créez un lien vers celui-ci depuis le fichier principal README.md. Par exemple :
README.md # with links to the specific docs.md
templates/
├── component-1/
│ ├── template.yml
│ └── docs.md
└── component-2/
├── template.yml
└── docs.md
Pour un exemple, consultez le README des composants AWS.
Il est fortement recommandé de tester les composants CI/CD dans le cadre du workflow de développement, ce qui permet de garantir un comportement cohérent.
Testez les modifications dans un pipeline CI/CD (comme tout autre projet) en créant un .gitlab-ci.yml dans le répertoire racine. Assurez-vous de tester à la fois le comportement et les effets secondaires potentiels du composant. Vous pouvez utiliser l'API GitLab si nécessaire.
Par exemple :
include:
# include the component located in the current project from the current SHA
- component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/my-component@$CI_COMMIT_SHA
inputs:
stage: build
stages: [build, test, release]
# Check if `component job of my-component` is added.
# This example job could also test that the included component works as expected.
# You can inspect data generated by the component, use GitLab API endpoints, or third-party tools.
ensure-job-added:
stage: test
image: badouralix/curl-jq
# Replace "component job of my-component" with the job name in your component.
script:
- |
route="${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/pipelines/${CI_PIPELINE_ID}/jobs"
count=`curl --silent --header "JOB-TOKEN: ${CI_JOB_TOKEN}" "$route" | jq 'map(select(.name | contains("component job of my-component"))) | length'`
if [ "$count" != "1" ]; then
exit 1; else
echo "Component Job present"
fi
# If the pipeline is for a new tag with a semantic version, and all previous jobs succeed,
# create the release.
create-release:
stage: release
image: registry.gitlab.com/gitlab-org/cli:latest
script: echo "Creating release $CI_COMMIT_TAG"
rules:
- if: $CI_COMMIT_TAG
release:
tag_name: $CI_COMMIT_TAG
description: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"
Après avoir commité et poussé les modifications, le pipeline teste le composant, puis crée une release si les jobs précédents réussissent.
[!note] Une authentification est nécessaire si le projet est privé.
Dans certains cas, les composants nécessitent des fichiers sources avec lesquels interagir. Par exemple, un composant qui construit du code source Go a probablement besoin de quelques exemples de Go à tester. De même, un composant qui construit des images Docker a probablement besoin de quelques exemples de Dockerfiles à tester.
Vous pouvez inclure ces exemples de fichiers directement dans le projet de composant, afin qu'ils soient utilisés pendant les tests du composant.
Vous pouvez en savoir plus dans les exemples de test d'un composant.
Lors de l'utilisation d'un autre composant dans votre composant, utilisez $CI_SERVER_FQDN à la place du nom de domaine pleinement qualifié de votre instance (comme gitlab.com).
Lors de l'accès à l'API GitLab dans votre composant, utilisez $CI_API_V4_URL plutôt que l'URL et le chemin complets de votre instance (comme https://gitlab.com/api/v4).
Ces variables prédéfinies garantissent que votre composant fonctionne également lorsqu'il est utilisé sur une autre instance, par exemple lors de l'utilisation de composants GitLab.com sur une instance GitLab Self-Managed.
Assurez-vous que le composant et son pipeline de test fonctionnent également sur GitLab Self-Managed. Alors que certaines ressources API de projets publics sur GitLab.com peuvent être accessibles avec des requêtes non authentifiées, sur une instance GitLab Self-Managed, un projet de composant peut être mis en miroir en tant que projet privé ou interne.
Il est important qu'un jeton d'accès puisse éventuellement être fourni via des entrées ou des variables pour authentifier les requêtes sur les instances GitLab Self-Managed.
Évitez d'utiliser des mots-clés globaux dans un composant. L'utilisation de ces mots-clés dans un composant affecte tous les jobs d'un pipeline, y compris les jobs directement définis dans le fichier principal .gitlab-ci.yml ou dans d'autres composants inclus.
En remplacement des mots-clés globaux :
extends dans le composant, mais utilisez des noms uniques qui réduisent le risque de conflits de noms lorsque le composant est fusionné dans la configuration.Par exemple, évitez d'utiliser le mot-clé global default :
# Not recommended
default:
image: ruby:3.0
rspec-1:
script: bundle exec rspec dir1/
rspec-2:
script: bundle exec rspec dir2/
À la place, vous pouvez :
Ajouter la configuration à chaque job explicitement :
rspec-1:
image: ruby:3.0
script: bundle exec rspec dir1/
rspec-2:
image: ruby:3.0
script: bundle exec rspec dir2/
Utiliser extends pour réutiliser la configuration :
.rspec-image:
image: ruby:3.0
rspec-1:
extends:
- .rspec-image
script: bundle exec rspec dir1/
rspec-2:
extends:
- .rspec-image
script: bundle exec rspec dir2/
Évitez d'utiliser des valeurs codées en dur dans les composants CI/CD. Les valeurs codées en dur peuvent obliger les utilisateurs du composant à examiner les détails internes du composant et à adapter leur pipeline pour travailler avec le composant.
Un mot-clé commun avec des valeurs codées en dur problématiques est stage. Si l'étape d'un job de composant est codée en dur, tous les pipelines utilisant le composant must soit définir exactement la même étape, soit remplacer la configuration.
La méthode préférée est d'utiliser le mot-clé input pour la configuration dynamique des composants. L'utilisateur du composant peut spécifier la valeur exacte dont il a besoin.
Par exemple, pour créer un composant avec une configuration stage pouvant être définie par les utilisateurs :
Dans la configuration du composant :
spec:
inputs:
stage:
default: test
---
unit-test:
stage: $[[ inputs.stage ]]
script: echo unit tests
integration-test:
stage: $[[ inputs.stage ]]
script: echo integration tests
Dans un projet utilisant le composant :
stages: [verify, release]
include:
- component: $CI_SERVER_FQDN/myorg/ruby/[email protected]
inputs:
stage: verify
Comme pour les valeurs du mot-clé stage, vous devriez éviter de coder en dur les noms de jobs dans les composants CI/CD. Lorsque les utilisateurs de votre composant peuvent personnaliser les noms de jobs, ils peuvent éviter les conflits avec les noms existants dans leurs pipelines. Les utilisateurs pourraient également inclure un composant plusieurs fois avec différentes options d'entrée en utilisant des noms différents.
Utilisez inputs pour permettre aux utilisateurs de votre composant de définir un nom de job spécifique, ou un préfixe pour le nom du job. Par exemple :
spec:
inputs:
job-prefix:
description: "Define a prefix for the job name"
job-name:
description: "Alternatively, define the job's name"
job-stage:
default: test
---
"$[[ inputs.job-prefix ]]-scan-website":
stage: $[[ inputs.job-stage ]]
script:
- scan-website-1
"$[[ inputs.job-name ]]":
stage: $[[ inputs.job-stage ]]
script:
- scan-website-2
Lors de l'utilisation de variables CI/CD dans un composant, évaluez si le mot-clé inputs doit être utilisé à la place. Évitez de demander aux utilisateurs de définir des variables personnalisées pour configurer des composants lorsque inputs est une meilleure solution.
Les entrées sont explicitement définies dans la section spec du composant et ont une meilleure validation que les variables. Par exemple, si une entrée requise n'est pas transmise au composant, GitLab renvoie une erreur de pipeline. En revanche, si une variable n'est pas définie, sa valeur est vide et il n'y a pas d'erreur.
Par exemple, utilisez inputs à la place de variables pour configurer le format de sortie d'un scanner :
Dans la configuration du composant :
spec:
inputs:
scanner-output:
default: json
---
my-scanner:
script: my-scan --output $[[ inputs.scanner-output ]]
Dans le projet utilisant le composant :
include:
- component: $CI_SERVER_FQDN/path/to/project/[email protected]
inputs:
scanner-output: yaml
Dans d'autres cas, les variables CI/CD peuvent toujours être préférées. Par exemple :
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Le Catalogue CI/CD est une liste de projets avec des composants CI/CD publiés que vous pouvez utiliser pour étendre votre workflow CI/CD.
N'importe qui peut créer un projet de composant et l'ajouter au Catalogue CI/CD, ou contribuer à un projet existant pour améliorer les composants disponibles.
Pour une démonstration interactive, voir la visite guidée du produit CI/CD Catalog en version bêta.
<!-- Demo published on 2024-01-24 -->Pour accéder au Catalogue CI/CD et afficher les composants publiés disponibles :
Autrement, si vous êtes déjà dans l'éditeur de pipeline de votre projet, vous pouvez sélectionner Catalogue CI/CD.
La visibilité des composants dans le catalogue CI/CD suit le paramètre de visibilité du projet source du composant. Les composants dont les projets sources sont définis sur :
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Si vous gérez des ressources du catalogue CI/CD, vous pouvez afficher des données d'analyse d'utilisation pour comprendre comment vos composants sont adoptés dans les projets.
Prérequis :
Pour afficher les données d'analyse des ressources du catalogue :
La vue Données d'analyse affiche les ressources du catalogue pour lesquelles vous avez le rôle Maintainer ou Owner. Cette vue affiche :
Par exemple :
Vous pouvez utiliser ces informations pour :
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Si vous gérez des projets de composants CI/CD du catalogue, vous pouvez afficher des informations détaillées sur l'utilisation des composants afin de comprendre quels projets les utilisent et quelles versions ils emploient. Cela vous aide à planifier les mises à niveau, communiquer les dépréciations et identifier les projets qui utilisent des versions obsolètes.
Prérequis :
Pour afficher les détails d'utilisation des composants :
Cet onglet liste les projets qui ont inclus l'un des composants de ce projet dans un pipeline au cours des 30 derniers jours. La liste inclut uniquement les projets que vous avez la permission de consulter.
Les détails incluent :
Les projets non visibles pour vous sont affichés comme Private project sans lien.
Vous pouvez utiliser ces informations pour :
Pour publier un projet de composant dans le catalogue CI/CD, vous devez :
Pour rendre les versions publiées d'un projet de composant visibles dans le catalogue CI/CD, vous devez définir le projet en tant que projet de catalogue.
Prérequis :
Pour définir le projet en tant que projet de catalogue :
Le projet ne devient trouvable dans le catalogue qu'après la publication d'une nouvelle release.
Pour utiliser l'automatisation afin d'activer ce paramètre, vous pouvez utiliser le point de terminaison GraphQL mutationcatalogresourcescreate. Le ticket 463043 propose d'exposer cela également dans l'API REST.
Les composants CI/CD peuvent être utilisés sans être répertoriés dans le catalogue CI/CD. Cependant, la publication des releases d'un composant dans le catalogue le rend découvrable par d'autres utilisateurs.
Prérequis :
README.md dans le répertoire racine pour le SHA de commit du tag en cours de publication.templates/ pour le SHA de commit du tag en cours de publication.release dans un job CI/CD pour créer la release, et non l'API Releases.Pour publier une nouvelle version du composant dans le catalogue :
Ajoutez un job au fichier .gitlab-ci.yml du projet qui utilise le mot-clé release pour créer la nouvelle release lorsqu'un tag est créé. Vous devriez configurer le pipeline de tag pour tester les composants avant d'exécuter le job de release. Par exemple :
create-release:
stage: release
image: registry.gitlab.com/gitlab-org/cli:latest
script: echo "Creating release $CI_COMMIT_TAG"
rules:
- if: $CI_COMMIT_TAG
release:
tag_name: $CI_COMMIT_TAG
description: "Release $CI_COMMIT_TAG of components in $CI_PROJECT_PATH"
Créez un nouveau tag pour la release, ce qui devrait déclencher un pipeline de tag contenant le job responsable de la création de la release. Le tag doit utiliser la gestion sémantique de version.
Une fois le job de release terminé avec succès, la release est créée et la nouvelle version est publiée dans le catalogue CI/CD.
{{< history >}}
{{< /history >}}
Lors du tagging et de la publication de nouvelles versions de composants dans le Catalogue, vous devez utiliser la gestion sémantique de version. La gestion sémantique de version est le standard pour indiquer qu'un changement est majeur, mineur, correctif ou d'un autre type.
Par exemple, 1.0.0, 2.3.4 et 1.0.0-alpha sont toutes des versions sémantiques valides.
Pour supprimer un projet de composant du catalogue, désactivez le bouton bascule CI/CD Catalog resource dans les paramètres du projet.
[!warning] Cette action détruit les métadonnées sur le projet de composant et ses versions publiées dans le catalogue. Le projet et son dépôt existent toujours, mais ne sont pas visibles dans le catalogue.
Pour publier à nouveau le projet de composant dans le catalogue, vous devez publier une nouvelle release.
{{< history >}}
{{< /history >}}
Certains composants CI/CD sont marqués d'une icône pour indiquer que le composant a été créé et est maintenu par des utilisateurs vérifiés par GitLab ou l'administrateur de l'instance :
GitLab-maintained ({{< icon name="tanuki-verified" >}}) : Composants GitLab.com créés et maintenus par GitLab.
GitLab Partner ({{< icon name="partner-verified" >}}) : Composants GitLab.com créés et maintenus de manière indépendante par un partenaire vérifié par GitLab.
Les partenaires GitLab peuvent contacter un membre de la GitLab Partner Alliance pour faire marquer leur espace de nommage sur GitLab.com comme vérifié par GitLab. Tous les composants CI/CD situés dans l'espace de nommage sont alors marqués comme composants GitLab Partner. Le membre de la Partner Alliance crée un ticket de demande interne (membres de l'équipe GitLab uniquement) au nom du partenaire vérifié.
[!warning] Les composants créés par des partenaires GitLab sont fournis as-is, sans garantie d'aucune sorte. L'utilisation par un utilisateur final d'un composant créé par un partenaire GitLab est à ses propres risques et GitLab n'aura aucune obligation d'indemnisation ni aucune responsabilité de quelque nature que ce soit en ce qui concerne l'utilisation du composant par l'utilisateur final. L'utilisation par l'utilisateur final d'un tel contenu et toute responsabilité y afférente incombent à l'éditeur du contenu et à l'utilisateur final.
Créateur vérifié ({{< icon name="check-sm" >}}) : Composants créés et maintenus par un utilisateur vérifié par un administrateur.
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Un administrateur GitLab peut définir un composant CI/CD comme créé et maintenu par un créateur vérifié :
Ouvrez GraphiQL dans l'instance avec votre compte administrateur, par exemple à : https://gitlab.example.com/-/graphql-explorer.
Exécutez cette requête, en remplaçant root-level-group par l'espace de nommage racine du composant à vérifier :
mutation {
verifiedNamespaceCreate(input: { namespacePath: "root-level-group",
verificationLevel: VERIFIED_CREATOR_SELF_MANAGED
}) {
errors
}
}
Une fois la requête terminée, tous les composants dans les projets de l'espace de nommage racine sont vérifiés. Le badge Créateur vérifié s'affiche à côté des noms des composants dans le catalogue CI/CD.
Pour supprimer le badge d'un composant, répétez la requête avec UNVERIFIED pour verificationLevel.
Tout template CI/CD existant que vous utilisez dans des projets avec la syntaxe include: peut être converti en composant CI/CD :
.gitlab-ci.yml dans le dépôt de composants pour tester les modifications du composant.Vous pouvez en savoir plus en suivant un exemple pratique de migration du template CI/CD Go vers un composant CI/CD.
{{< details >}}
{{< /details >}}
Le catalogue CI/CD d'une nouvelle installation d'une instance GitLab ne contient aucun composant CI/CD publié. Pour remplir le catalogue de votre instance, vous pouvez :
Pour mettre en miroir un composant GitLab.com dans votre instance GitLab Self-Managed :
gitlab.com.components).Comme n'importe qui peut publier des composants dans le catalogue, vous devez examiner soigneusement les composants avant de les utiliser dans votre projet. L'utilisation des composants CI/CD GitLab se fait à vos propres risques et GitLab ne peut pas garantir la sécurité des composants tiers.
Lors de l'utilisation de composants CI/CD tiers, tenez compte des bonnes pratiques de sécurité suivantes :
latest.CI_JOB_TOKEN) pour les projets utilisant des composants CI/CD.Pour maintenir des composants CI/CD sécurisés et fiables et garantir l'intégrité de la configuration du pipeline que vous fournissez aux utilisateurs, suivez ces bonnes pratiques :
No one pour les branches protégées.latest : Évitez d'inclure des exemples dans votre README.md qui utilisent @latest.content not found {#content-not-found-message}Vous pourriez recevoir un message d'erreur similaire à celui ci-dessous lors de l'utilisation de ~latest ou d'un qualificateur de version sémantique partielle pour référencer un composant hébergé par un projet de catalogue :
This GitLab CI configuration is invalid: Component 'gitlab.com/my-namespace/my-project/my-component@~latest' - content not found
Le comportement de ~latest a été mis à jour dans GitLab 16.10. Il fait désormais référence à la dernière version sémantique de la ressource du catalogue. Pour résoudre ce problème, créez une nouvelle release.
Build component error: Spec must be a valid json schema {#error-build-component-error-spec-must-be-a-valid-json-schema}Si un composant a un formatage invalide, vous pourriez ne pas être en mesure de créer une release et pourriez recevoir une erreur comme Build component error: Spec must be a valid json schema.
Cette erreur peut être causée par une section spec:inputs vide. Si votre configuration n'utilise pas d'entrées, vous pouvez laisser la section spec vide à la place. Par exemple :
spec:
---
my-component:
script: echo