Créer des pipelines conditionnels avec CEL


  • FrançaisFrançais



  • Vous venez de suivre un guide pour démarrer votre pipeline (ou tâche) Tekton lorsqu’une demande de fusion est créée ou mise à jour sur votre projet GitLab. Vous avez donc configuré GitLab pour envoyer une demande de fusion événements comme webhooks. Et vous avez déployé quelques tekton Composants:

    • EventListener: reçoit les webhooks de GitLab
    • Gâchette: démarre votre Pipeline à chaque fois que l’EventListener reçoit un nouveau webhook de GitLab
    • Pipeline: récupère le code source de GitLab et le construit

    Ensuite, vous remarquez que tout événement dans votre demande de fusion (un nouveau commentaire, un changement de balise) déclenche le pipeline. Ce n’est pas le comportement que vous désirez. Vous n’avez pas besoin de créer un commentaire ou une balise, après tout. Vous voulez que le pipeline ne s’exécute que lorsqu’il y a un nouveau code à créer. Voici comment j’utilise CEL Interceptor de Tekton pour créer des conditions pour mes pipelines.

    Préparez votre déclencheur

    Je suppose que vous avez déjà défini un déclencheur. C’est probablement quelque chose de similaire à l’extrait ci-dessous.

    L’intercepteur du déclencheur rejette tout ce qui ne provient pas d’une demande de fusion. Pourtant, l’intercepteur n’est pas en mesure de faire la différence entre les mises à jour de code et les mises à jour sans code (comme les nouveaux commentaires).

    apiVersion: triggers.tekton.dev/v1beta1
    kind
    : Trigger
    metadata
    :
      name
    : webhook-listener-trigger
    spec
    :
      interceptors
    :
       # reject any payload that's not a merge request webhook
        - name
    : "filter-event-types"
          ref
    :
            name
    : "gitlab"
            kind
    : ClusterInterceptor
          params
    :
            - name
    : eventTypes
              value
    :
               - "Merge Request Hook"
      bindings
    :
        - ref
    : binding
      template
    :
        ref
    : template

    Ajouter un intercepteur CEL

    Voici le cel intercepteur. Cet intercepteur filtre la charge utile du webhook à l’aide du langage d’expression CEL. Si l’expression de filtre est évaluée à truele pipeline démarre.

    Ici, je vérifie le object_attributes.oldrev doit exister dans le corps JSON de la charge utile du webhook. Si object_attributes.oldrev existe, cela signifie que cet événement concerne un changement de code. S’il n’y a pas eu de changement de code, il n’y a pas de révision précédente (oldrev) se référer à.

    spec:
      interceptors
    :
        - name
    : "allow-code-changes-only"
          ref
    :
            name
    : cel
            kind
    : ClusterInterceptor
          params
    :
            - name
    : filter
              value
    : >
               has(body.object_attributes.oldrev)

    Ajoutez le nouvel intercepteur à votre déclencheur. Maintenant, votre déclencheur ressemble à ceci :

    apiVersion: triggers.tekton.dev/v1beta1
    kind
    : Trigger
    metadata
    :
      name
    : gitlab-listener-trigger
    spec
    :
      interceptors
    :
        - name
    : "verify-gitlab-payload"
          ref
    :
            name
    : "gitlab"
            kind
    : ClusterInterceptor
          params
    :
            - name
    : eventTypes
              value
    :
               - "Merge Request Hook"
        - name
    : "allow-code-changes-only"
          ref
    :
            name
    : "cel"
            kind
    : ClusterInterceptor
          params
    :
            - name
    : filter
              value
    : >
               has(body.object_attributes.oldrev)
      bindings
    :
        - ref
    : binding
      template
    :
        ref
    : template

    Déployez cette nouvelle version du déclencheur et profitez des pouvoirs de l’automatisation. À partir de maintenant, votre pipeline ne démarre que s’il y a du nouveau code à construire.

    Des astuces

    Il n’y a pas de limites aux conditions que vous pouvez définir dans un filtre CEL.

    Vous pouvez vérifier que la demande de fusion est actuellement ouverte :

    body.object_attributes.state in ['opened']

    Vous pouvez vous assurer que le contributeur a terminé son travail sur le code :

    body.object_attributes.work_in_progress == false

    Il vous suffit de concaténer correctement plusieurs conditions :

    - name: filter
      value
    : >
       has(body.object_attributes.oldrev) &&
        body.object_attributes.state in ['opened'] &&
        body.object_attributes.work_in_progress == false

    Vérifiez événements de demande de fusion documentation pour vous inspirer pour rédiger vos propres conditions.

    Vous aurez peut-être besoin du Définition du langage CEL savoir comment traduire vos pensées en code.

    Pour évaluer des types autres que des chaînes, vous souhaitez connaître le mappage entre JSON et CEL les types.

    Source

    N'oubliez pas de voter pour cet article !
    1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
    Loading...

    La Rédaction

    L'équipe rédactionnnelle du site

    Pour contacter personnellement le taulier :

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée.