IBM Cloud Docs
Cómo trabajar con Tekton Pipelines

Cómo trabajar con Tekton Pipelines

Tekton Pipelines es un proyecto de código abierto que puede utilizar para configurar y ejecutar Integración Continua y Continuous Delivery pipelines dentro de un cluster Kubernetes. Los conductos de Tekton se definen en los archivos yaml que se suelen almacenar en un repositorio Git (repo).

Tuberías Tekton " caption-side="bottom"} de tuberías Tekton{: caption="

Tekton proporciona un conjunto de extensiones de recursos personalizados a Kubernetes para definir canalizaciones. Los siguientes recursos básicos de Tekton Pipeline se incluyen en estas extensiones:

Recursos de tuberías Tekton
Recurso Descripción
Task Define un conjunto de pasos de compilación como, por ejemplo un código de compilación, pruebas de ejecución e imágenes de compilación y despliegue.
TaskRun Crea una instancia de una tarea para que se ejecute con parámetros específicos de entrada, salida y ejecución. Puede iniciar la tarea por sí sola o como parte de un conducto.
Pipeline Define el conjunto de tareas que componen un conducto.
PipelineRun Crea una instancia de un conducto para que se ejecute con parámetros específicos de entrada, salida y ejecución.

Puede aprovechar las características siguientes cuando utilice Tekton Pipelines:

  • Cloud nativo: Tekton Pipelines se ejecuta en Kubernetes, utiliza clústeres de Kubernetes como tipo de primera clase y utiliza contenedores como bloques de compilación.
  • Desacoplado: Puede utilizar un conducto para desplegarlo en algún clúster de Kubernetes. Puede ejecutar las tareas que componen un conducto de forma aislada. Y puede cambiar los recursos (por ejemplo, los repositorios de Git) entre ejecuciones de conductos.
  • Con tipo: Puede conmutar las implementaciones para tipos específicos de recursos como, por ejemplo, imágenes.

El proyecto Tekton Pipelines es un release beta. Debe actualizar su conducto con cada nueva versión de Tekton. Para más información sobre la última versión de Tekton, consulte https://github.com/tektoncd/pipeline/releases.

IBM Cloud® Continuous Delivery proporciona dos tipos de conductos de entrega que el usuario puede utilizar para compilar, probar y desplegar sus aplicaciones.

  • Clásico: Los conductos de entrega clásicos se crean de forma gráfica con el estado habilitado en el diagrama de conductos. Estos conductos se pueden ejecutar en trabajadores compartidos en la nube o en trabajadores privados que se ejecutan en su propio clúster de Kubernetes.
  • Tekton: Los conductos de entrega de Tekton se crean dentro de archivos yaml que definen los conductos como un conjunto de recursos de Kubernetes. Puede editar esos archivos yaml para cambiar el comportamiento de una canalización. Los conductos de Tekton se pueden ejecutar en trabajadores privados que se ejecutan en su propio clúster. También se pueden ejecutar en los trabajadores gestionados por IBM en la nube pública. La integración de Tekton proporciona un panel de control que puede utilizar para ver el estado de las ejecuciones de canalización de Tekton y activar nuevas ejecuciones. También proporciona mecanismos para especificar los desencadenantes de interconexión, las definiciones de interconexión, el trabajador en el que se ejecuta la interconexión y las propiedades de interconexión.

Ambos tipos de conductos aíslan trabajos o pasos entre sí ejecutándose en contenedores independientes y utilizando una imagen de su elección. Tanto los pipelines clásicos como los de Tekton existen en una cadena de herramientas y dependen de ella para añadir más integraciones de herramientas que se utilizan en los procesos de compilación, prueba y despliegue.

El 20 de noviembre de 2020, Dockerhub incorporó la limitación de tasas en las extracciones de imágenes anónimas. Este cambio puede afectar a los usuarios que ejecutan tareas que hacen referencia a imágenes alojadas en Dockerhub. Se recomienda utilizar un registro alternativo, como por ejemplo IBM Cloud Container Registry.

Requisitos previos

Antes de añadir y ejecutar un conducto Tekton, asegúrese de que tiene los siguientes recursos en su lugar:

  • Una cadena de herramientas que contiene las siguientes integraciones de herramientas:

    • Una integración de herramientas de repositorio (como, por ejemplo, la integración de herramientas de GitHub) que contiene el código de conducto de Tekton, incluido un archivo yaml de Tekton. Encuentre ejemplos de definiciones de canalizaciones y tareas en GitHub. Para obtener más información sobre cómo empezar a utilizar los pipelines Tekton, consulte Pipelines Tekton.
    • Opcional. Si no utiliza el nodo trabajador de conducto compartido predeterminado, puede utilizar una integración de herramientas de un nodo trabajador privado de Delivery Pipeline que haga referencia a su clúster de Kubernetes. Para obtener más información sobre los trabajadores privados, consulte Instalación de trabajadores privados de Delivery Pipeline.
  • La CLI de IBM Cloud instalada localmente.

  • kubectl instalado localmente.

  • Un clúster de Kubernetes (versión 1.22 o superior) como, por ejemplo, un clúster de IBM Cloud® Kubernetes Service.

La cadena de herramientas y la integración de herramientas del trabajador privado de Delivery Pipeline deben estar en la misma región.

Creación de un Delivery Pipeline para Tekton utilizando la consola

Cuando configure una integración de herramientas de Delivery Pipeline, puede seleccionar el tipo de conducto que desea crear.

  1. Si no tiene una cadena de herramientas, seleccione una plantilla para crear una. En función de la plantilla que utilice, los campos disponibles serán distintos. Revise los valores del campo predeterminado y, si es necesario, realice cambios.

  2. Si tiene una cadena de herramientas y está agregando esta integración de herramientas a ella, desde la consola IBM Cloud, haga clic en el ícono de Menú ícono de hamburguesa > Automatización de la plataforma > Cadenas de herramientas. En la página de cadenas de herramientas, haga clic en la cadena de herramientas para abrir su página de descripción general. Como alternativa, en la página Visión general de su app, en la tarjeta de Entrega continua, pulse Ver cadena de herramientas. A continuación, pulse Visión general.

  3. Añada la integración de Delivery Pipeline a la cadena de herramientas:

    a. Pulse Añadir herramienta.

    b. En la sección Integraciones de herramientas, pulse Delivery Pipeline.

  4. Especifique un nombre para el nuevo conducto.

  5. Seleccione Tekton para crear un Delivery Pipeline de Tekton. Puede ver el resultado de las ejecuciones de canalización de Tekton en un clúster definido de Kubernetes, con soporte para configurar los repositorios de definiciones de canalización, los disparadores de canalización, dónde se ejecuta la canalización y secretos sencillos.

  6. Si tiene previsto utilizar el conducto para desplegar una interfaz de usuario, marque el recuadro de selección Mostrar apps en el menú Ver app. Todas las apps creadas por el conducto se muestran en la lista Ver app de la página de visión general de la cadena de herramientas.

  7. Pulse Crear integración para añadir el Delivery Pipeline a la cadena de herramientas.

Configuración de Delivery Pipeline para Tekton utilizando la consola

  1. En la página Visión general de su cadena de herramientas, en la tarjeta Tuberías de entrega, haga clic en el botón Delivery Pipeline para abrir la página Tekton Delivery Pipeline Overview.

  2. Pulse Valores. En la sección Definiciones, lleve a cabo las tareas siguientes:

    a. Especifique el repositorio Git y el URL que contiene la definición del conducto de Tekton y artefactos relacionados. Si el repositorio no está disponible, vuelva a la página Visión general de la cadena de herramientas y añada el repositorio.

    b. Seleccione la rama dentro de su repositorio de Git que desea utilizar o escriba una etiqueta.

    c. Especifique la vía de acceso en la definición de conductos dentro del repositorio de Git. Puede hacer referencia a una definición específica dentro del mismo repositorio. También puede añadir varios repositorios de definición, si están integrados con la cadena de herramientas.

    d. Guarde los cambios.

    La definición de conducto se actualiza automáticamente.

    El límite calculado para el tamaño de la definición de la interconexión es de 1 MB. Si se genera algún error al guardar o ejecutar la interconexión, es posible que sea necesario reducir el tamaño de la definición de la interconexión o dividirla entre varias interconexiones.

  3. En la sección Nodo trabajador, seleccione el nodo trabajador compartido gestionado de IBM o el nodo trabajador privado que desea utilizar para ejecutar el conducto de Tekton. Para obtener más información sobre los trabajadores privados, consulte Cómo trabajar con trabajadores privados de Delivery Pipeline.

    El trabajador privado debe estar definido en la misma cadena de herramientas como conducto de Tekton.

  4. En la sección Propiedades del entorno, pulse Añadir y seleccione un tipo de propiedad para definir su propia propiedad de entorno. Por ejemplo, puede definir una propiedad de API_KEY que pase una clave de API que se utiliza para que todos los scripts del conducto accedan a los recursos de IBM Cloud. Puede añadir los siguientes tipos de propiedades:

    • Enumeración: Una clave de propiedad con un valor que se puede seleccionar de una lista de opciones definida por el usuario.
    • Valor seguro: Una clave de propiedad con un valor de una sola línea que está protegido con cifrado AES-128. Este valor se visualiza utilizando el carácter de asterisco. También puede pulsar el icono Clave para seleccionar un secreto de una integración de caja fuerte (como IBM Key Protect), si hay alguna herramienta de este tipo disponible en la cadena de herramientas.
    • Valor de texto: Una clave de propiedad con un valor de texto que puede ser una sola línea o varias líneas. Anteriormente, los valores de varias líneas recibían soporte mediante un tipo de propiedad Área de texto independiente.
    • Integración de herramientas: Una clave de propiedad con un valor que se resuelve en el tiempo de ejecución desde una integración de cadena de herramientas. De forma predeterminada, el valor es una representación de serie JSON de la integración de herramientas. Se puede recuperar un campo o subconjunto específico del objeto proporcionando un valor para el filtro JSON opcional. Por ejemplo, si se selecciona una integración de GitHub y se especifica el filtro JSON parameters.repo_url, el valor refleja el URL del repositorio Git que se ha configurado en la integración de herramientas cuando se ejecuta el recurso PipelineRun.

    Puede acceder a estas propiedades en sus recursos de conductos de Tekton. Para obtener más información sobre estas propiedades, consulte Entornos y recursos de Tekton Pipelines.

    Las propiedades se pueden bloquear para evitar que se alteren temporalmente. Si se intenta alterar temporalmente una propiedad bloqueada en tiempo de ejecución, se rechazará la solicitud de ejecución. Las propiedades bloqueadas no se visualizan de forma predeterminada en el panel lateral de ejecución, pero se pueden visualizar de sólo lectura habilitando la opción 'Mostrar todas las propiedades'.

  5. Pulse Guardar.

  6. En la página Descripción general de la canalización, haga clic en Añadir para crear un activador, seleccione el tipo de activador que desea añadir y asócielo a un receptor de eventos. La lista de escuchas de sucesos disponibles incluye los escuchas definidos en el repositorio de código de la interconexión.

    Los disparadores se basan en las definiciones de disparador de Tekton. Git los activadores de repositorio utilizan el receptor de eventos al que están asignados para extraer información de la carga útil del evento entrante y crear recursos en Kubernetes. Estos recursos se aplican a un recurso PipelineRun de Tekton.

    Las ejecuciones de interconexiones desencadenadas se ejecutan simultáneamente, a menos que se configure el desencadenante para serializar las ejecuciones utilizando la opción Limit concurrent runs. Si se habilita esta opción, se puede limitar el número de ejecuciones simultáneas que puede iniciar el desencadenante. Por ejemplo, si el límite máximo se establece en 1, solo se efectúa una ejecución de interconexión para este desencadenante cada vez, las restantes pasan a formar parte de una cola con estado en espera. Un máximo de 20 ejecuciones (5 si utiliza IBM Managed Workers) se ponen en cola en estado de espera antes de que las solicitudes posteriores se cancelen automáticamente. De forma predeterminada, todos los activadores temporizados están limitados a una ejecución simultánea cuando se utilizan IBM Managed Workers

    Los desencadenantes manuales se ejecutan cuando se pulsa el botón de conducto Ejecutar y se selecciona el desencadenante.

    Los desencadenantes de repositorio Git se ejecutan cuando se produce el tipo de suceso Git especificado para el repositorio y la rama de Git especificados.

    Puede acceder a la carga útil de webhook que se entrega a un desencadenante de Git desde los recursos de conducto de Tekton. Aunque los campos exactos son específicos de repositorio, la sintaxis general de la carga útil de webhook es $(event.payloadFieldName). Para poder crear un webhook, debe autorizar el acceso de administración de Git para la integración de Git correspondiente. Para autorizar el acceso de administración de Git, configure y guarde la integración de Git de nuevo.

    Los disparadores temporizados se ejecutan a una hora programada definida por el valor CRON. La expresión CRON para los disparadores temporizados se basa en la sintaxis crontab de UNIX y es una secuencia de cinco campos de fecha y hora: minute, hour, day of the month, month, y day of the week. Estos campos están separados por espacios en el formato X X X X X. La frecuencia máxima de un desencadenante temporizado es una vez cada cinco minutos. En los ejemplos siguientes, se muestran series que utilizan diferentes frecuencias temporizadas.

    • */5 * * * * - El desencadenante se ejecuta cada 5 minutos.
    • 0 * * * * - El desencadenante se ejecuta al principio de cada hora.
    • 0 9 * 1 MON-FRI - El desencadenante se ejecuta a las 9:00 todos los días de la semana en enero.
    • 0 * * NOV,DEC 1 - El desencadenante se ejecuta cada hora los lunes durante los meses de noviembre y diciembre.

    Los desencadenantes de webhook genéricos se ejecutan cuando una se envía solicitud POST configurada con el valor secreto al URL de webhook genérico. Los desencadenantes de webhook genéricos ofrecen un URL de webhook exclusivo para solicitudes POST.

    Puesto que la interfaz de usuario de PipelineRun no oculta los valores de carga útil de webhook genéricos en la sección de carga útil del suceso, no incluya datos confidenciales en la carga útil. En su lugar, proteja los datos que necesita un webhook genérico mediante propiedades de desencadenante, como contraseñas o secretos de claves de API.

    Puede proteger los desencadenantes de webhook genéricos para que funcionen con Git, con un webhook de salida de Slack, con un webhook Artifactory o más mediante cualquiera de los métodos siguientes:

    • Comparaciones de señales para comparar la señal guardada y la señal que se pasa con la solicitud POST. Los orígenes de señales admitidos incluyen una cabecera, una consulta o una carga útil. Los webhooks de GitLab y los webhooks de salida de Slack utilizan comparaciones de señales.
    • Comparaciones de digest de carga útil para comparar la signatura y el valor hash que se generan en la carga útil de digest mediante digest hex HMAC con una señal guardada. Los orígenes de signatura admitidos incluyen una cabecera, una consulta o una carga útil. Los usuarios deben especificar un algoritmo de digest. Los webhooks de GitHub utilizan comparaciones de digest de carga útil.
    • La validación de tareas de Tekton requiere que los usuarios validen la solicitud de webhook dentro de sus tareas de Tekton.

    Especifique los siguientes valores para utilizar desencadenantes de webhook genéricos con webhooks de GitHub:

    • Protección: Payload Digest Matches
    • Origen de signatura: Header
    • Nombre de clave de cabecera: X-Hub-Signature
    • Algoritmo digest: sha1.

    Especifique los siguientes valores para utilizar desencadenantes de webhook genéricos con webhooks de GitLab:

    • Protección: Token Matches
    • Origen de señal: Header
    • Nombre de clave de cabecera: X-Gitlab-Token

    Especifique los siguientes valores para utilizar desencadenantes de webhook genéricos con webhooks de salida de Slack:

    • Protección: Token Matches
    • Origen de señal: Payload
    • Nombre de propiedad JSON / Clave de formato: token

    En el siguiente ejemplo se muestra cómo utilizar el mandato curl con un webhook genérico que está protegido con una regla Token Matches:

    Ejemplo de webhook " caption-side="bottom"} de webhook{: 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"
    }'
    

    Para obtener valores de carga útil en la definición del conducto, especifique un parámetro Triggerbinding con un valor que se haya derivado del suceso:

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

    Guarde los cambios.

    Además, los activadores de webhook genéricos admiten la transmisión de propiedades en el cuerpo de la solicitud de webhook. Esto permite anular las propiedades de PipelineRun activadas por el webhook, o pasar propiedades adicionales que complementen las propiedades de canalización/activación utilizadas en PipelineRun.

    Si necesita introducir datos confidenciales en las propiedades de la carga útil, como contraseñas o claves secretas de API, debe utilizar el tipo de propiedad SECURE para que no se muestren en texto sin formato en la interfaz de usuario.

    Además, se puede pasar una descripción opcional en el cuerpo de la solicitud que describa el PipelineRun que se activa, y que se muestra en la interfaz de usuario cuando se visualizan los detalles de PipelineRun en un navegador.

    El siguiente ejemplo muestra cómo utilizar el comando curl con un webhook genérico pasando una propiedad text, una propiedad secure y una descripción:

    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"}
      ]
    }'
    

Configuración de disparadores Delivery Pipeline para pipelines Tekton

Puede configurar disparadores para los pipelines de Tekton basados en varios eventos en su Git repo. Filtra los disparadores Git utilizando las siguientes opciones:

  • Rama: Activa el pipeline para una rama específica del repositorio seleccionado cuando se produce el evento especificado.
  • Patrón: Activa la canalización basándose en una coincidencia global con etiquetas y nombres de rama en el repositorio seleccionado cuando se produce el evento especificado.
  • Filtro CEL: Activa la canalización cuando el evento coincide con el filtro Common Expression Language (CEL) proporcionado.

Utilice las opciones Rama y Patrón para especificar eventos como " commit push", " pull request opened, " updated o " closed. Además, puede especificar eventos de solicitud de extracción cambiando la opción Incluir eventos de solicitud de extracción de bor radores para permitir u omitir activadores de canalización para solicitudes de extracción de borradores. Del mismo modo, puede especificar si desea permitir la activación de canalización para las solicitudes de extracción de repositorios bifurcados mediante el uso de la Incluir eventos de solicitud de extracción de bifurcaciones. Además, puede seleccionar la opción Filtros de etiquetas para activar el filtrado basado en las etiquetas de las solicitudes pull según los criterios definidos por el usuario en la tabla de filtros.

La opción de filtro CEL admite casos de uso más avanzados, como la comparación con otros campos de la carga útil del evento. Esta opción soporta eventos push, todos los eventos pull request, eventos issues, eventos issue comments y eventos release. Esta opción también está disponible como una característica opcional en el desencadenador Generic Webhook para proporcionar filtrado de eventos basado en la carga útil del webhook.

Visión general del CEL

CEL es un lenguaje de expresión potente y flexible diseñado para evaluar condiciones y realizar validaciones de forma concisa y legible. CEL es ideal para casos de uso que requieren una lógica condicional compleja, como el filtrado de eventos.

En Tekton pipeline, se introduce la opción CEL para proporcionar un filtrado de eventos más potente y flexible. La carga útil del webhook se evalúa con respecto a la expresión CEL proporcionada por el usuario. Si la expresión CEL se evalúa como true, se activa la ejecución de la canalización.

CEL admite las siguientes funciones:

  • Operadores aritméticos (+, -, *, /, %)
  • Operadores de comparación (=, !=, <, >, <=, >=)
  • Operadores lógicos (&&, ||)
  • Operadores de cadena (contains, matches, startsWith, endsWith)
  • Operadores de recogida (in, !in)
  • Variables (refiérase a las variables directamente por su nombre)
  • Literales (admite literales como cadenas, números, booleanos y nulos)

CEL incluye las siguientes extensiones para proporcionar más funcionalidad al lenguaje CEL base:

  • Sets extension para soportar operaciones de conjunto avanzadas y proporcionar más flexibilidad en el filtrado de eventos. Para obtener más información sobre esta extensión, consulte Conjuntos.
  • matchesGlob para proporcionar compatibilidad al convertir el campo de patrón existente a la nueva opción de filtro CEL. El operador nativo de CEL matches se recomienda para coincidencias de expresiones regulares más avanzadas.

Para obtener más información sobre CEL, consulte la documentación sobre CEL.

Conversión a CEL

Complete los siguientes pasos para convertir su selección de filtrado de eventos existente en una expresión CEL:

  1. Edite el disparador Git que desea convertir.

  2. En la sección Desencadenar en, seleccione la opción FiltroCEL.

    CEL filter option
    CEL filter option

    Los siguientes elementos se convierten automáticamente en una expresión CEL equivalente:

    • Rama o patrón
    • Eventos, como commit push, pull request opened, updated y closed
    • Incluir borradores de pull request
    • Incluir eventos pull request de forks
    • Filtros de etiqueta

    CEL filter conversion
    CEL filter conversion

    La expresión CEL generada se escribe en un campo de área de texto, que puede editar según sea necesario.

    Dado que no existen filtros en los desencadenadores Webhook genéricos para la conversión, la conversión a un filtro CEL sólo se aplica a los desencadenadores Git.

    Si guarda el disparador con la opción CEL seleccionada, sustituirá los eventos previamente seleccionados por la expresión CEL. Si cambia a la opción Rama o Patrón después de guardar la opción de filtro CEL, no se guardarán las selecciones de eventos anteriores. No se admite la conversión de la opción CEL a la opción Rama o Patrón.

Ejemplos de expresión CEL

Los siguientes ejemplos son expresiones CEL comunes para cada uno de los tipos Git soportados: GitHub, GitLab y BitBucket. Puede copiar y modificar estos ejemplos para adaptarlos a sus necesidades.

GitHub:

Se ejecuta cuando se abre o actualiza un pull request contra la rama especificada:

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

Se ejecuta cuando se envía una confirmación a la rama especificada:

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

Se ejecuta cuando se envía una confirmación a la rama especificada, pero se omite cuando el mensaje de confirmación contiene una cadena específica:

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

Se ejecuta cuando se añade a un pull request un comentario que contiene la cadena especificada:

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

Se ejecuta cuando se crea una incidencia con la etiqueta especificada:

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

GitLab:

Se ejecuta cuando se abre o actualiza una solicitud de fusión contra la rama especificada:

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

Se ejecuta cuando se envía una confirmación a la rama especificada:

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

Se ejecuta cuando se envía una confirmación a la rama especificada, pero se omite cuando el mensaje de confirmación contiene una cadena específica:

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

Se ejecuta cuando se añade a una solicitud de fusión un comentario que contiene la cadena especificada:

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

Se ejecuta cuando se crea una incidencia con la etiqueta especificada:

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

BitBucket:

Se ejecuta cuando se abre o actualiza un pull request contra la rama especificada:

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

Se ejecuta cuando se envía una confirmación a la rama especificada:

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

Se ejecuta cuando se envía una confirmación a la rama especificada, pero se omite cuando el mensaje de confirmación contiene una cadena específica:

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

Se ejecuta cuando se añade a un pull request un comentario que contiene la cadena especificada:

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

Se ejecuta cuando se crea una incidencia con la etiqueta especificada:

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

Filtros

Los filtros permiten a los usuarios refinar las solicitudes de extracción en función de criterios específicos. Actualmente, el campo de filtrado permite especificar etiquetas en las solicitudes de extracción, controlando así la ejecución de la canalización en función de su presencia o ausencia. Sin embargo, no activa una canalización cuando se añaden o eliminan etiquetas, sino que verifica las etiquetas del RP antes de permitir la ejecución de la canalización.

Cómo funciona:

  • Si se produce un evento PR (como la adición de un nuevo commit), el pipeline comprueba las etiquetas del PR.
  • Si el RP cumple las condiciones de la etiqueta (por ejemplo, tiene la etiqueta "aprobado"), la canalización se pone en marcha.
  • Si el RP no cumple las condiciones de la etiqueta, la canalización no se ejecutará.

Configuración de ejemplo

La siguiente captura de pantalla muestra un ejemplo en el que el activador está configurado para las etiquetas "aprobado" y "revisado".

  • El proceso PR sólo se activará si ambas etiquetas están presentes.
  • Si falta alguna de las etiquetas, la canalización no se ejecutará.

Configuración de filtros de etiquetas para la ejecución de canalizaciones PR
Configuración de filtros de etiquetas para la ejecución de canalizaciones PR

Comprobación de la carga útil del evento

Cuando escriba expresiones CEL para filtrar eventos, debe comprender la estructura y el contenido de la carga útil del webhook contra la que se evaluará la expresión. Puede inspeccionar la carga útil de una ejecución existente desde la página de detalles de la ejecución del pipeline.

Para ver la carga útil del evento, vaya a la página de detalles de la ejecución de la tubería y haga clic en Mostrar contexto. Puede ver la carga útil sin procesar del webhook que desencadenó la ejecución de la canalización y confirmar los campos relevantes para que sus expresiones CEL coincidan con las condiciones que desea.

Creación de un Delivery Pipeline para Tekton con la API

  1. Obtener una señal portadora de IAM. De forma alternativa, si utiliza un SDK, obtenga una clave de API de IAM y establezca las opciones de cliente utilizando variables de entorno.

    export CD_TEKTON_PIPELINE_APIKEY={api_key}
    
  2. Determine la región y el ID de la cadena de herramientas a la que desea añadir la integración de herramientas de Delivery Pipeline.

  3. Añada la integración de herramientas de Delivery Pipeline a la cadena de herramientas.

    curl -X POST \
      https://api.{region}.devops.cloud.ibm.com/toolchain/v2/toolchains/{toolchain_id}/tools \
      -H 'Authorization: Bearer {iam_token}' \
      -H 'Accept: application/json` \
      -H 'Content-Type: application/json' \
      -d '{
        "tool_type_id": "pipeline",
        "parameters": {
          "name": "{tool_integration_name}",
          "type" : "tekton"
        }
      }'
    
    const CdToolchainV2 = require('@ibm-cloud/continuous-delivery/cd-toolchain/v2');
    ...
    (async () => {
       const toolchainService = CdToolchainV2.newInstance();
       const pipelinePrototypeModel = {
          toolchainId: {toolchain_id},
          toolTypeId: 'pipeline',
          name: {tool_integration_name},
          type: "tekton"
       };
       const pipelineTool = await toolchainService.createTool(pipelinePrototypeModel);
    })();
    
    import (
    	   "github.com/IBM/continuous-delivery-go-sdk/cdtoolchainv2"
    )
    ...
    toolchainClientOptions := &cdtoolchainv2.CdToolchainV2Options{}
    toolchainClient, err := cdtoolchainv2.NewCdToolchainV2UsingExternalConfig(toolchainClientOptions)
    createPipelineToolOptions := toolchainClient.NewCreateToolOptions({toolchain_id}, "pipeline")
    createPipelineToolOptions.SetName({tool_integration_name})
    createPipelineToolOptions.SetType("tekton")
    pipelineTool, response, err := toolchainClient.CreateTool(createPipelineToolOptions)
    
    from ibm_continuous_delivery.cd_toolchain_v2 import CdToolchainV2
    ...
    toolchain_service = CdToolchainV2.new_instance()
    pipeline_tool = toolchain_service.create_tool(
       name = {tool_integration_name},
       toolchain_id = {toolchain_id},
       tool_type_id = "pipeline",
       type = "tekton"
    )
    
    import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.CdToolchain;
    import com.ibm.cloud.continuous_delivery.cd_toolchain.v2.model.*;
    ...
    CdToolchain toolchainService = CdToolchain.newInstance();
    CreateToolOptions createPipelineToolOptions = new CreateToolOptions.Builder()
       .name({tool_integration_name})
       .toolchainId({toolchain_id})
       .toolTypeId("pipeline")
       .type("tekton")
       .build();
    Response<ToolchainToolPost> response = toolchainService.createTool(createPipelineToolOptions).execute();
    ToolchainToolPost pipelineTool = response.getResult();
    

    La tabla siguiente lista y describe cada una de las variables que se utilizan en el paso anterior.

    Variables para añadir la integración de la herramienta Delivery Pipeline con la API
    Variable Descripción
    {region} La región en la que reside la cadena de herramientas, por ejemplo, us-south.
    {tool_integration_name} Un nombre para la integración de herramientas, por ejemplo, ci-pipeline.
    {toolchain_id} El ID de la cadena de herramientas a la que añadir la integración de herramientas.
    {iam_token} Un token de portador IAM válido.
  4. Configure Delivery Pipeline para utilizar trabajadores gestionados públicos dentro de las regiones especificadas.

    curl -X POST \
       https://api.{region}.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines \
       -H 'Authorization: Bearer {iam_token}' \
       -H 'Accept: application/json` \
       -H 'Content-Type: application/json' \
       -d '{
          "id": "{pipeline_id}",
          "worker": { "id": "public" }
       }'
    
    const CdTektonPipelineV2 = require('@ibm-cloud/continuous-delivery/cd-tekton-pipeline/v2');
    ...
    (async () => {
       const tektonService = CdTektonPipelineV2.newInstance();
       const workerIdentityModel = {
          id: 'public',
       };
       const params = {
          id: {pipeline_id},
          worker: workerIdentityModel,
       };
       const res = await tektonService.createTektonPipeline(params);
    })();
    
    import {
       "github.com/IBM/continuous-delivery-go-sdk/cdtektonpipelinev2"
    }
    ...
    cdTektonPipelineOptions := &cdtektonpipelinev2.CdTektonPipelineV2Options{}
    pipelineSvc, err = cdtektonpipelinev2.NewCdTektonPipelineV2UsingExternalConfig(cdTektonPipelineOptions)
    createTektonPipelineOptions := pipelineSvc.NewCreateTektonPipelineOptions(
       {pipeline_id}
    )
    workerIdentityModel := &cdtektonpipelinev2.WorkerIdentity{
       ID: core.StringPtr("public"),
    }
    createTektonPipelineOptions.SetWorker(workerIdentityModel)
    tektonPipeline, response, err := pipelineSvc.CreateTektonPipeline(createTektonPipelineOptions)
    
    from ibm_continuous_delivery.cd_tekton_pipeline_v2 import CdTektonPipelineV2
    ...
    pipeline_service = CdTektonPipelineV2.new_instance()
    worker_identity_model = {
       'id': 'public',
    }
    response = pipeline_service.create_tekton_pipeline(
       id = {pipeline_id},
       worker = worker_identity_model
    )
    tekton_pipeline = response.get_result()
    
    import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.CdTektonPipeline;
    import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.model.*;
    ...
    CdTektonPipeline pipelineSvc = CdTektonPipeline.newInstance();
    WorkerIdentity workerIdentityModel = new WorkerIdentity.Builder()
       .id("public")
       .build();
    CreateTektonPipelineOptions createTektonPipelineOptions = new CreateTektonPipelineOptions.Builder()
       .id({pipeline_id})
       .worker(workerIdentityModel)
       .build();
    Response<TektonPipeline> response = pipelineSvc.createTektonPipeline(createTektonPipelineOptions).execute();
    TektonPipeline tektonPipeline = response.getResult();
    

    La tabla siguiente lista y describe cada una de las variables que se utilizan en el paso anterior.

    Variables para configurar el Delivery Pipeline con la API
    Variable Descripción
    {region} La región en la que reside la cadena de herramientas, por ejemplo, us-south.
    {pipeline_id} El ID de la interconexión que se devuelve del paso anterior donde se ha creado la integración de la herramienta de interconexión.
    {iam_token} Un token de portador IAM válido.

Para más información sobre la API Delivery Pipeline, consulte los documentos de la API.

Creación de un Delivery Pipeline para Tekton con Terraform

  1. Para instalar la CLI de Terraform y configurar el plug-in de proveedor de IBM Cloud para Terraform, siga la guía de aprendizaje Cómo empezar con Terraform en IBM Cloud®.

  2. Cree un archivo de configuración de Terraform denominado main.tf. En este archivo, añada la configuración para crear una canalización utilizando el lenguaje de configuración HashiCorp. Para obtener más información sobre cómo utilizar este idioma de configuración, consulte la documentación de Terraform.

    Un conducto debe pertenecer a una cadena de herramientas. También puede crear cadenas de herramientas utilizando Terraform.

    El ejemplo siguiente crea una cadena de herramientas y un conducto utilizando los recursos de Terraform especificados.

    data "ibm_resource_group" "group" {
      name = "default"
    }
    
    resource "ibm_cd_toolchain" "my_toolchain" {
      name              = "terraform_toolchain"
      resource_group_id = data.ibm_resource_group.group.id
    }
    
    resource "ibm_cd_toolchain_tool_pipeline" "my_pipeline_tool" {
      parameters {
         name = "terraform-pipeline-integration"
      }
      toolchain_id = ibm_cd_toolchain.my_toolchain.id
    }
    
    resource "ibm_cd_tekton_pipeline" "my_tekton_pipeline" {
     worker {
         id = "public"
     }
     pipeline_id = ibm_cd_toolchain_tool_pipeline.my_pipeline_tool.tool_id
    }
    

    Para obtener más información sobre los recursos ibm_cd_toolchain_tool_pipeline y ibm_cd_tekton_pipeline, consulte los detalles de referencia de argumentos en la documentación del registro de Terraform.

  3. Inicialice la CLI de Terraform, si es necesario.

    terraform init
    
  4. Cree un plan de ejecución de Terraform. Este plan resume todas las acciones que deben ejecutarse para crear una cadena de herramientas.

    terraform plan
    
  5. Aplique el plan de ejecución de Terraform. Terraform realiza todas las acciones necesarias para crear la cadena de herramientas.

    terraform apply
    

Visualización de un Delivery Pipeline para Tekton

Puede ver un conducto utilizando la interfaz de usuario de la consola, con la API o con Terraform.

Visualización de un Delivery Pipeline utilizando la consola

La página Visión general de Tekton Delivery Pipeline muestra una tabla vacía hasta que se añada al menos un desencadenante. Después de que se produzcan ejecuciones de interconexión de Tekton (ya sea manualmente o como resultado de sucesos externos), la tabla muestra datos sobre las ejecuciones recientes que están asociadas con cada desencadenante en la interconexión. Cada fila muestra información sobre un único desencadenante y muestra un gráfico de las ejecuciones recientes que están asociadas con dicho desencadenante. También se muestra información como, por ejemplo, el éxito o el error de estas ejecuciones y la hora en que se ha producido la ejecución más reciente. También puede realizar acciones para cada desencadenante: ejecutar el desencadenante manualmente, marcarlo como favorito, editar el desencadenante, habilitarlo o inhabilitarlo, o suprimirlo. También puede pulsar uno de los elementos del gráfico para inspeccionar los detalles de ese PipelineRun individual. O bien, puede pulsar un nombre de desencadenante para abrir la página PipelineRuns en cada PipelineRun asociado con ese desencadenante. También está disponible información relacionada como, por ejemplo, el estado, el desencadenante y la duración de cada PipelineRun.

Las ejecuciones de conductos pueden tener cualquiera de los estados siguientes:

  • Pendiente: se solicita PipelineRun.
  • En ejecución: PipelineRun se está ejecutando en el clúster.
  • Realizado correctamente: PipelineRun se ha completado correctamente en el clúster.
  • Ha fallado: PipelineRun ha fallado. Revise el archivo de registro de la ejecución para determinar la causa.
  • En cola: PipelineRun se ha aceptado para su proceso y se ejecuta cuando haya disponible capacidad de trabajador.
  • En espera: PipelineRun está a la espera de ponerse en cola.
  • Cancelado: PipelineRun se ha cancelado por el sistema o por el usuario. El sistema cancela una PipelineRun cuando el número de ejecuciones en espera supera el límite permitido.
  • Error: PipelineRun contiene errores que han impedido que se aplicara en el clúster. Para obtener más información sobre la causa del error, consulte los detalles de la ejecución.

Para obtener información detallada sobre una ejecución seleccionada, pulse cualquier fila de la tabla para ver la definición de Task y los pasos de cada definición de PipelineRun. También puede ver el estado, los registros y los detalles de cada definición y paso de la Task así como el estado general de la definición de PipelineRun.

El periodo de retención para PipelineRuns y sus registros depende del plan seleccionado para la instancia de servicio de Continuous Delivery. Los conductos de Tekton bajo el plan Professional se conservan durante un año. Los conductos de Tekton bajo el plan Lite se conservan durante 30 días. Para conservar cualquier PipelineRuns después del periodo de retención, en la sección PipelineRuns, seleccione Acciones > Descargar** para descargar un archivo .zip.

Visualización de un Delivery Pipeline con la API

  1. Obtener una señal portadora de IAM. De forma alternativa, si utiliza un SDK, obtenga una clave de API de IAM y establezca las opciones de cliente utilizando variables de entorno.

    export CD_TEKTON_PIPELINE_APIKEY={api_key}
    
  2. Obtenga los datos de interconexión.

    curl -X GET \
      https://api.{region}.devops.cloud.ibm.com/pipeline/v2/tekton_pipelines/{pipeline_id} \
      -H 'Authorization: Bearer {iam_token}' \
      -H 'Accept: application/json`
    
    const CdTektonPipelineV2 = require('@ibm-cloud/continuous-delivery/cd-tekton-pipeline/v2');
    ...
    (async () => {
       const pipelineSvc = CdTektonPipelineV2.newInstance();
       const params = {
          id: {pipeline_id},
       };
       const res = await pipelineSvc.getTektonPipeline(params);
    })();
    
    import {
       "github.com/IBM/continuous-delivery-go-sdk/cdtektonpipelinev2"
    }
    ...
    cdTektonPipelineOptions := &cdtektonpipelinev2.CdTektonPipelineV2Options{}
    pipelineSvc, err = cdtektonpipelinev2.NewCdTektonPipelineV2UsingExternalConfig(cdTektonPipelineOptions)
    getTektonPipelineOptions := pipelineSvc.NewGetTektonPipelineOptions(
       {pipeline_id}
    )
    tektonPipeline, response, err := pipelineSvc.GetTektonPipeline(getTektonPipelineOptions)
    
    from ibm_continuous_delivery.cd_tekton_pipeline_v2 import CdTektonPipelineV2
    ...
    pipeline_service = CdTektonPipelineV2.new_instance()
    response = pipeline_service.get_tekton_pipeline(
       id = {pipeline_id}
    )
    tekton_pipeline = response.get_result()
    
    import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.CdTektonPipeline;
    import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.model.*;
    ...
    CdTektonPipeline pipelineSvc = CdTektonPipeline.newInstance();
    GetTektonPipelineOptions getTektonPipelineOptions = new GetTektonPipelineOptions.Builder()
       .id({pipeline_id})
       .build();
    Response<TektonPipeline> response = pipelineSvc.getTektonPipeline(getTektonPipelineOptions).execute();
    TektonPipeline tektonPipeline = response.getResult();
    

La tabla siguiente lista y describe cada una de las variables que se utilizan en el paso anterior.

Variables para ver el Delivery Pipeline con la API
Variable Descripción
{region} La región en la que reside la interconexión, por ejemplo, us-south.
{pipeline_id} El ID de la tubería que desea ver.
{iam_token} Un token de portador IAM válido.

Visualización de un Delivery Pipeline con Terraform

  1. Localice el archivo Terraform (por ejemplo, main.tf) que contiene el bloque resource para la interconexión existente.

  2. Añada un bloque output al archivo Terraform, si todavía no contiene un bloque.

    El resource del ejemplo siguiente describe una interconexión existente. El bloque output indica a Terraform que genere los atributos del recurso especificado.

    data "ibm_resource_group" "group" {
      name = "default"
    }
    
    resource "ibm_cd_toolchain" "my_toolchain" {
      name              = "terraform_toolchain"
    resource_group_id = data.ibm_resource_group.group.id
    }
    
    resource "ibm_cd_toolchain_tool_pipeline" "my_pipeline_tool" {
      parameters {
        name = "terraform-pipeline-integration"
      }
      toolchain_id = ibm_cd_toolchain.my_toolchain.id
    }
    
    resource "ibm_cd_tekton_pipeline" "my_tekton_pipeline" {
      worker {
        id = "public"
      }
      pipeline_id = ibm_cd_toolchain_tool_pipeline.my_pipeline_tool.tool_id
    }
    
    output "my_tekton_pipeline_attributes" {
      value = ibm_cd_tekton_pipeline.my_tekton_pipeline
    }
    

    Para obtener más información sobre los recursos ibm_cd_toolchain_tool_pipeline y ibm_cd_tekton_pipeline, consulte los detalles de referencia de argumentos en la documentación del registro de Terraform.

  3. Inicialice la CLI de Terraform, si es necesario.

    terraform init
    
  4. Aplique el plan de ejecución de Terraform con la opción refresh-only. Terraform renueva su estado y muestra los atributos del recurso de interconexión.

    terraform apply -refresh-only -auto-approve
    

Borrar un Delivery Pipeline con la API

  1. Obtener una señal portadora de IAM. De forma alternativa, si utiliza un SDK, obtenga una clave de API de IAM y establezca las opciones de cliente utilizando variables de entorno.

    export CD_TEKTON_PIPELINE_APIKEY={api_key}
    
  2. Determine la región y el ID de la cadena de herramientas a la que desea añadir la integración de la herramienta DevOps Insights.

  3. Suprima la interconexión.

    curl -X DELETE \
      https://api.{region}.devops.cloud.ibm.com/toolchain/v2/toolchains/{toolchain_id}/tools/{pipeline_id} \
      -H 'Authorization: Bearer {iam_token}'
    
    const CdTektonPipelineV2 = require('@ibm-cloud/continuous-delivery/cd-tekton-pipeline/v2');
    ...
    (async () => {
       const pipelineSvc = CdTektonPipelineV2.newInstance();
       const params = {
          id: {pipeline_id},
       };
       const res = await pipelineSvc.deleteTektonPipeline(params);
    })();
    
    import {
       "github.com/IBM/continuous-delivery-go-sdk/cdtektonpipelinev2"
    }
    ...
    cdTektonPipelineOptions := &cdtektonpipelinev2.CdTektonPipelineV2Options{}
    pipelineSvc, err = cdtektonpipelinev2.NewCdTektonPipelineV2UsingExternalConfig(cdTektonPipelineOptions)
    deleteTektonPipelineOptions := pipelineSvc.NewDeleteTektonPipelineOptions(
       {pipeline_id}
    )
    response, err := pipelineSvc.DeleteTektonPipeline(deleteTektonPipelineOptions)
    
    from ibm_continuous_delivery.cd_tekton_pipeline_v2 import CdTektonPipelineV2
    ...
    pipeline_service = CdTektonPipelineV2.new_instance()
    response = pipeline_service.delete_tekton_pipeline(
       id={pipeline_id}
    )
    
    import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.CdTektonPipeline;
    import com.ibm.cloud.continuous_delivery.cd_tekton_pipeline.v2.model.*;
    ...
    CdTektonPipeline pipelineSvc = CdTektonPipeline.newInstance();
    DeleteTektonPipelineOptions deleteTektonPipelineOptions = new DeleteTektonPipelineOptions.Builder()
       .id({pipeline_id})
       .build();
    Response<Void> response = pipelineSvc.deleteTektonPipeline(deleteTektonPipelineOptions).execute();
    

La tabla siguiente lista y describe cada una de las variables que se utilizan en el paso anterior.

Variables para eliminar el Delivery Pipeline con la API
Variable Descripción
{region} La región en la que reside la cadena de herramientas, por ejemplo, us-south.
{toolchain_id} El ID de la cadena de herramientas que contiene el conducto que se va a suprimir.
{pipeline_id} El ID de la canalización que desea eliminar.
{iam_token} Un token de portador IAM válido.

Supresión de un Delivery Pipeline con Terraform

  1. Localice el archivo Terraform (por ejemplo, main.tf) que contiene el bloque resource para la interconexión existente.

    El resource del ejemplo siguiente describe una interconexión existente.

    data "ibm_resource_group" "group" {
      name = "default"
    }
    
    resource "ibm_cd_toolchain" "my_toolchain" {
      name              = "terraform_toolchain"
      resource_group_id = data.ibm_resource_group.group.id
    }
    
    resource "ibm_cd_toolchain_tool_pipeline" "my_pipeline_tool" {
      parameters {
         name = "terraform-pipeline-integration"
      }
      toolchain_id = ibm_cd_toolchain.my_toolchain.id
    }
    
    resource "ibm_cd_tekton_pipeline" "my_tekton_pipeline" {
     worker {
         id = "public"
     }
     pipeline_id = ibm_cd_toolchain_tool_pipeline.my_pipeline_tool.tool_id
    }
    
  2. Elimine los bloques ibm_cd_toolchain_tool_pipeline y ibm_cd_tekton_pipeline resource del archivo Terraform.

  3. Inicialice la CLI de Terraform, si es necesario.

    terraform init
    
  4. Cree un plan de ejecución de Terraform. Este plan resume todas las acciones que se deben ejecutar para suprimir el conducto.

    terraform plan
    
  5. Aplique el plan de ejecución de Terraform. Terraform realiza todas las acciones necesarias para suprimir la interconexión.

    terraform apply
    

Visualización de los detalles de un pod de TaskRun

Para ver información sobre el pod Kubernetes subyacente para un TaskRun específico, haga clic en el nombre Task y, a continuación, en Pod.

Puede ver los detalles del pod y todos los sucesos relacionados notificados por el trabajador. Esta información puede ayudarle a depurar errores específicos o a determinar a qué se dedica el tiempo durante una ejecución.

Más información sobre los conductos y recursos de Tekton

Para obtener más información sobre los pipelines de Tekton, consulte los artículos Tekton: Un enfoque moderno para Continuous Delivery y Herramientas y recursos de Tekton Pipelines IBM Cloud Continuous Delivery.

Para obtener más información sobre las tareas Tekton a las que puede hacer referencia en sus pipelines, consulte el Catálogo Tekton de Open Toolchain. Este repositorio de GitHub contiene un conjunto de tareas que puede reutilizar en los conductos de Tekton.