Configuration d'un Delivery Pipeline pour Tekton à l'aide de la console

1. Dans la page Aperçu de votre chaîne d'outils, sur la carte Pipelines de livraison, cliquez sur le bouton Delivery Pipeline pour ouvrir la page Tekton Delivery Pipeline Overview.

2. Cliquez sur Paramètres. Dans la section Définitions, effectuez les opérations suivantes :

   a. Spécifiez le référentiel Git et l'URL contenant la définition du pipeline Tekton et les artefacts associés. Si votre référentiel n'est pas disponible, retournez à la page de présentation de la chaîne d'outils et ajoutez votre référentiel.

   b. Sélectionnez la branche de votre référentiel Git que vous souhaitez utiliser ou entrez une étiquette.

   c. Indiquez le chemin d'accès à votre définition de pipeline dans le référentiel Git. Vous pouvez faire référence à une définition spécifique dans le même référentiel. Vous pouvez également ajouter plusieurs référentiels de définitions, s'ils sont intégrés à la chaîne d'outils.

   d. Sauvegardez vos modifications.

   La définition du pipeline est mise à jour automatiquement.

   La limite de capacité de calcul du pipeline est de 1 Mo. Si vous rencontrez des erreurs lors de la sauvegarde ou de l'exécution de votre pipeline, vous devrez peut-être réduire la taille de votre définition de pipeline ou la diviser en plusieurs pipelines.

3. Dans la section Agent, sélectionnez l'agent partagé géré par IBM ou l'agent privé à utiliser pour exécuter votre pipeline Tekton. Pour plus d'informations sur les agents privés, voir Utilisation des agents privés Delivery Pipeline.

   L'agent privé doit être défini dans la même chaîne d'outils que votre pipeline Tekton.

4. Dans la section des propriétés de l'environnement, cliquez sur Ajouter et sélectionnez un type de propriété pour définir votre propre propriété d'environnement. Par exemple, vous pouvez définir une propriété API_KEY qui transmet une clé d'API utilisée par tous les scripts du pipeline pour accéder aux ressources IBM Cloud. Vous pouvez ajouter les types de propriétés suivants :

   • Enumération : Clé de propriété ayant une valeur qui peut être sélectionnée à partir d'une liste d'options définie par l'utilisateur.
   • Valeur sécurisée : Clé de propriété avec une valeur monoligne qui est sécurisée avec le chiffrement AES-128. Cette valeur s'affiche en utilisant l'astérisque. Vous pouvez également cliquer sur l'icône de clé pour sélectionner un secret à partir d'une intégration de coffre (tel que IBM Key Protect), si un tel outil est disponible dans votre chaîne d'outils.
   • Valeur texte: Clé de propriété avec une valeur de texte qui peut être une ligne simple ou être multi-lignes. Auparavant, les valeurs multi-lignes étaient prises en charge par un type de propriété Zone de texte distinct.
   • Intégration d'outils : Clé de propriété avec une valeur résolue lors de l'exécution à partir d'une intégration d'outils de la chaîne d'outils. Par défaut, la valeur est une représentation de chaîne JSON de l'intégration d'outils. Une zone ou un sous-ensemble spécifique de l'objet peut être extrait en fournissant une valeur pour le filtre JSON facultatif. Par exemple, si une intégration GitHub est sélectionnée et que le filtre JSON parameters.repo_url est spécifié, la valeur correspond à l'URL du référentiel Git qui est configuré dans l'intégration de l'outil lors de l'exécution de la ressource PipelineRun.

   Vous pouvez accéder à ces propriétés dans vos ressources de pipeline Tekton. Pour plus d'informations sur ces propriétés, voir Environnement et ressources des pipelines Tekton.

   Les propriétés peuvent être verrouillées pour éviter qu'elles ne soient remplacées. La tentative de remplacement d'une propriété verrouillée lors de l'exécution entraînera le rejet de la demande d'exécution. Les propriétés verrouillées ne sont pas affichées par défaut dans le panneau latéral d'exécution mais peuvent être affichées en lecture seule en activant l'option'Afficher toutes les propriétés'.

5. Cliquez sur Sauvegarder.

6. Sur la page Présentation de la pipeline, cliquez sur Ajouter pour créer un déclencheur, sélectionnez le type de déclencheur à ajouter et associez le déclencheur à un récepteur d'événements. La liste des programmes d'écoute d'événement disponibles contient les programmes d'écoute définis dans le code du référentiel de pipeline.

   Les déclenchements sont basés sur les définitions des déclencheurs Tekton. Git les déclencheurs de repo utilisent l'écouteur d'événement auquel ils sont associés pour extraire des informations de la charge utile de l'événement entrant et créer des ressources Kubernetes. Ces ressources sont appliquées à une ressource PipelineRun Tekton.

   Les exécutions de pipeline déclenchées sont exécutées simultanément, sauf si vous configurez le déclencheur pour sérialiser les exécutions à l'aide de l'option Limit concurrent runs. Lorsque cette option est activée, vous pouvez limiter le nombre d'exécutions simultanées pouvant être démarrées par ce déclencheur. Par exemple, si la limite maximale est fixée à 1, un seul pipeline est exécuté à la fois pour ce déclencheur et tous les autres sont mis en file d'attente dans l'état "Waiting". Un maximum de 20 exécutions (5 si vous utilisez IBM Managed Workers) sont mises en attente avant que les demandes suivantes ne soient automatiquement annulées. Par défaut, tous les déclencheurs temporisés sont limités à une exécution simultanée lorsqu'ils utilisent IBM Managed Workers

   Lorsqu'un déclencheur dépasse sa limite d'exécution simultanée, les nouvelles exécutions de pipeline sont placées dans un état d'attente jusqu'à ce que la capacité devienne disponible. Si vous le souhaitez, ce comportement peut être modifié de manière à ce que seule l'exécution la plus récente puisse être en état d'attente et que les autres exécutions soient automatiquement annulées. Cela peut être utile, par exemple, pour les déclencheurs Git, si vous ne souhaitez construire que la livraison la plus récente lorsque plusieurs exécutions sont déclenchées dans un court laps de temps. Pour activer cette fonction, un interrupteur "Limit to one waiting run" est disponible dans le panneau de configuration du déclencheur, qui peut également être défini via l'API à l'aide de la propriété limit_waiting_runs (voir la documentation de l'API). Notez que ce paramètre ne s'applique qu'aux courses en état d'attente et n'affecte pas les courses actives.

   Les déclencheurs manuels sont exécutés lorsque vous cliquez sur le bouton Exécuter du pipeline, puis sélectionnez le déclencheur.

   Les déclencheurs de référentiel Git sont exécutés lorsque le type d'événement Git spécifié se produit pour le référentiel Git et la branche spécifiés.

   Vous pouvez accéder au contenu des webhooks qui est fourni à un déclencheur Git à partir de vos ressources de pipeline Tekton. Bien que les zones exactes soient propres au référentiel, la syntaxe générale pour le contenu des webhooks est $(event.payloadFieldName). Avant de créer un webhook, vous devez autoriser l'accès à Git Admin pour l'intégration Git correspondante. Pour autoriser l'accès à Git Admin, configurez et sauvegardez à nouveau l'intégration Git.

   Les déclencheurs temporisés s'exécutent à une heure programmée définie par la valeur CRON. L'expression CRON pour les déclencheurs temporisés est basée sur la syntaxe crontab d'UNIX et est une séquence de cinq champs d'heure et de date : minute, hour, day of the month, month, et day of the week. Ces zones sont séparées par des espaces au format X X X X X. La fréquence maximale d'un déclencheur temporisé est une fois toutes les cinq minutes. Les exemples suivants illustrent des chaînes qui utilisent différentes fréquences temporisées :

   • */5 * * * * - Le déclencheur s'exécute toutes les 5 minutes.
   • 0 * * * * - Le déclencheur s'exécute au début de chaque heure.
   • 0 9 * 1 MON-FRI - Le déclencheur s'exécute à 9 heures tous les jours de la semaine de janvier.
   • 0 * * NOV,DEC 1 - Le déclencheur s'exécute toutes les heures les lundis de novembre et de décembre.

   Les déclencheurs de webhook générique sont exécutés lorsqu'une demande POST qui est configurée avec la valeur du secret est transférée à l'URL du webhook générique. Les déclencheurs de webhook générique fournissent une URL de webhook unique pour les demandes POST.

   Etant donné que l'interface utilisateur de PipelineRun ne masque pas les valeurs de contenu de webhook générique dans la section du contenu de l'événement, n'incluez pas de données sensibles dans le contenu. A la place, sécurisez les données requises par un webhook générique en utilisant des propriétés de déclenchement, telles que des mots de passe ou des secrets de clé d'API.

   Vous pouvez sécuriser les déclencheurs de webhook générique pour qu'ils fonctionnent avec Git, un webhook sortant Slack, un webhook Artifactory, etc., à l'aide d'une des méthodes suivantes :

   • Correspondances de jeton (Token Matches) pour comparer le jeton sauvegardé au jeton transféré dans la demande POST. Les sources de jeton prises en charge comprennent un en-tête, une requête ou un contenu. Les correspondances de jeton sont utilisées par les webhooks GitLab et les webhooks sortants Slack.
   • Correspondances de prétraitement de contenu (Payload Digest Matches) pour comparer la signature et la valeur de hachage générée à partir du contenu pré-traité à l'aide d'une méthode HMAC hex digest avec le jeton sauvegardé. Les sources de signature prises en charge peuvent inclure un en-tête, une requête ou un contenu. Les utilisateurs doivent indiquer un algorithme de prétraitement (digest). Les correspondances de prétraitement de contenu sont utilisées par les webhooks GitHub.
   • La validation de tâche Tekton (Tekton Task Validation) nécessite que les utilisateurs valident la demande du webhook dans leurs tâches Tekton.

   Indiquez les valeurs suivantes pour utiliser des déclencheurs de webhook générique avec des webhooks GitHub :

   • Sécurisation : Payload Digest Matches
   • Source de la signature : Header
   • Nom de clé d'en-tête : X-Hub-Signature
   • Algorithme de prétraitement : sha1.

   Indiquez les valeurs suivantes pour utiliser des déclencheurs de webhook générique avec des webhooks GitLab :

   • Sécurisation : Token Matches
   • Source du jeton : Header
   • Nom de clé d'en-tête : X-Gitlab-Token

   Indiquez les valeurs suivantes pour utiliser des déclencheurs de webhook générique avec des webhooks sortants Slack :

   • Sécurisation : Token Matches
   • Source du jeton : Payload
   • Nom de la propriété JSON / clé de formulaire : token

   L'exemple suivant présente comment utiliser la commande curl avec un webhook générique sécurisé avec une règle Token Matches :

   {: caption="

   curl -X POST \
   https://devops-api.us-south.devops.cloud.ibm.com/v1/tekton-webhook/588236be-749b-4c67-ae57-a561abbbc9a8/run/7e82880e-4223-4c98-8ca9-ef6df36bb6dc \
   -H 'Content-Type: application/json' \
   -H 'token: 48a0f92c0932890048596906a22ae189c48c5619fbcf9600' \
   -d '{
   "somekey": "somevalue"
   }'
   

   Pour obtenir les valeurs de contenu dans la définition de pipeline, spécifiez un paramètre Triggerbinding avec une valeur dérivée de l'événement :

   apiVersion: tekton.dev/v1beta1
   kind: TriggerBinding
   metadata:
   name: binding
   spec:
   params:
   - name: somekey
   value: $(event.somekey)
   

   Sauvegardez vos modifications.

   En outre, les déclencheurs génériques de webhook permettent de transmettre des propriétés dans le corps de la demande de webhook. Cela permet de remplacer les propriétés du site PipelineRun qui est déclenché par le webhook, ou de transmettre des propriétés supplémentaires qui complètent les propriétés du pipeline/déclencheur utilisées dans le site PipelineRun.

   Si vous devez transmettre des données sensibles dans les propriétés de la charge utile, telles que des mots de passe ou des secrets de clés API, vous devez utiliser le type de propriété SECURE pour ces propriétés afin qu'elles ne soient pas affichées en texte clair dans l'interface utilisateur.

   En outre, une description facultative peut être transmise dans le corps de la demande, qui décrit le site PipelineRun déclenché et qui est affichée dans l'interface utilisateur lorsque les détails du site PipelineRun sont consultés dans un navigateur.

   L'exemple suivant montre comment utiliser la commande curl avec un webhook générique en transmettant une propriété textuelle, une propriété sécurisée et une description :

   curl -X POST \
   https://devops-api.us-south.devops.cloud.ibm.com/v1/tekton-webhook/588236be-749b-4c67-ae57-a561abbbc9a8/run/7e82880e-4223-4c98-8ca9-ef6df36bb6dc \
   -H 'Content-Type: application/json' \
   -H 'token: 48a0f92c0932890048596906a22ae189c48c5619fbcf9600' \
   -d '{
     "description":"This text can be used to describe the PipelineRun that will be triggered by this request.",
     "properties":[
       {"name":"mytextprop","type":"TEXT","value":"my text value"},
       {"name":"mysecureprop","type":"SECURE","value":"mysecret"}
     ]
   }'
   

Configuration des déclencheurs Delivery Pipeline pour les pipelines Tekton

Vous pouvez configurer des déclencheurs pour les pipelines Tekton en fonction de divers événements dans votre Git repo. Filtrez les déclencheurs Git en utilisant les options suivantes :

• Branche: Déclencher le pipeline pour une branche spécifique du repo sélectionné lorsque l'événement spécifié se produit.
• Modèle: Déclencher le pipeline sur la base d'une correspondance globale avec les tags et les noms de branches dans le repo sélectionné lorsque l'événement spécifié se produit.
• Filtre CEL: Déclencher le pipeline lorsque l'événement correspond au filtre CEL (Common Expression Language) fourni.

Utilisez les options Branche et Motif pour spécifier des événements tels que " commit push, " pull request opened, " updated ou " closed. Vous pouvez également spécifier des événements de demande d'extraction en modifiant l'option Inclure les événements de demande d'extraction de brouillon pour autoriser ou ignorer les déclenchements de pipeline pour les demandes d'extraction de brouillon. De même, vous pouvez spécifier si vous souhaitez autoriser les déclenchements de pipeline pour les demandes de téléchargement provenant de dépôts forkés en utilisant la case à cocher Inclure les événements de demandes de téléchargement provenant de dépôts forkés. En outre, vous pouvez sélectionner l'option Filtres d'étiquettes pour activer le filtrage basé sur les étiquettes des demandes de retrait selon des critères définis par l'utilisateur dans le tableau des filtres.

L'option de filtre CEL prend en charge des cas d'utilisation plus avancés, tels que la mise en correspondance avec d'autres champs dans la charge utile de l'événement. Cette option prend en charge les événements "push", tous les événements "pull request", les événements "issues", les événements "issue comments" et les événements "release". Cette option est également disponible en tant que fonctionnalité facultative sur le déclencheur générique de webhook pour permettre le filtrage des événements sur la base de la charge utile du webhook.

   header['x-github-event'] == 'pull_request' &&
      (body.action == 'opened' || body.action == 'synchronize') &&
      body.pull_request.base.ref == 'main'

   header['x-github-event'] == 'push' && body.ref == 'refs/heads/main'

   header['x-github-event'] == 'push' &&
      body.ref == 'refs/heads/main' &&
      !body.head_commit.message.contains("skip run")

   header['x-github-event'] == 'issue_comment' &&
      body.action == 'created' && has(body.issue.pull_request) &&
      body.comment.body.contains('/lgtm')

   header['x-github-event'] == 'issues' &&
      body.action == 'opened' &&
      body.issue.labels.exists(label, label.name == 'urgent')

   header['x-gitlab-event'] == 'Merge Request Hook' &&
      (body.object_attributes.action == 'open' || body.object_attributes.action == 'update') &&
      body.object_attributes.target_branch == 'main'

   header['x-gitlab-event'] == 'Push Hook' && body.ref == 'refs/heads/main'

   header['x-gitlab-event'] == 'Push Hook' &&
      body.ref == 'refs/heads/main' &&
      !body.object_attributes.last_commit.message("skip run")

   header['x-gitlab-event'] == 'Note Hook' &&
      body.object_attributes.noteable_type == 'MergeRequest' &&
      body.object_attributes.action == 'create' &&
      body.object_attributes.note.contains('/lgtm')

   header['x-gitlab-event'] == 'Issue Hook' &&
      (body.object_attributes.action == 'open') &&
      body.object_attributes.labels.exists(label, label.name == 'urgent')

   (header['x-event-key'] == 'pullrequest:created' || header['x-event-key'] == 'pullrequest:updated') &&
       body.pullrequest.destination.branch.name == 'main'

   header['x-event-key'] == 'repo:push' && body.push.changes[0].new.name == 'main'

   header['x-event-key'] == 'repo:push' &&
      body.push.changes[0].new.name == 'main' &&
      !body.push.changes[0].commits[0].message("skip run")

   header['x-event-key'] == 'pullrequest:comment_created' &&
      body.comment.content.raw.contains('/lgtm')

   header['x-event-key'] == 'issue:created' &&
      body.issue.kind == 'bug'