Configuración de Delivery Pipeline para Tekton utilizando la consola

1. Desde la página Descripción general de tu cadena de herramientas, en la ficha Canales de entrega, haz clic en Delivery Pipeline para abrir la página Descripción general de Tekton Delivery Pipeline.

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 del pipeline, haz clic en Añadir para crear un disparador, selecciona el tipo de disparador que deseas añadir y asocia el disparador a un detector 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 disparadores de Tekton. Git Los disparadores de repositorio utilizan el detector de eventos al que están asignados para extraer información de la carga útil del evento entrante y crear recursos de 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 ejecutará una vez el pipeline asociado a este desencadenador y el resto se pondrán en cola en estado En espera. Se ponen en cola un máximo de 20 ejecuciones (5 si se utilizan trabajadores gestionados de IBM ) en estado de espera antes de que las solicitudes posteriores se cancelen automáticamente. De forma predeterminada, todos los desencadenantes temporizados están limitados a una ejecución simultánea cuando se utilizan los trabajadores gestionados de IBM.

   Cuando un desencadenante supera su límite de ejecuciones simultáneas, las nuevas ejecuciones se colocan en un estado de "espera" hasta que haya capacidad disponible. Si se desea, este comportamiento puede modificarse para que sólo la ejecución más reciente pueda estar en estado "Esperando" y otras ejecuciones de este tipo se cancelen automáticamente. Esto puede resultar útil, por ejemplo, para Git desencadenantes si solo desea compilar la confirmación más reciente cuando se desencadenan múltiples ejecuciones en un breve periodo de tiempo. Para habilitar esta función, en el panel de configuración del disparador se encuentra disponible un conmutador "Limitar a una ejecución en espera", que también puede establecerse a través de la API mediante la propiedad limit_waiting_runs (consulte los documentos de la API ). Tenga en cuenta que este ajuste sólo se aplica a las ejecuciones en estado "En espera" y no afecta a las ejecuciones activas.

   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 desencadenantes temporizados se ejecutan a una hora programada que viene definida por el valor CRON. La expresión CRON para los desencadenantes temporizados se basa en la sintaxis de 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](images/pipeline_tekton_generic_webhook.png){: 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 admite eventos push, todos los eventos de solicitudes pull, eventos de incidencias, eventos de comentarios de incidencias, eventos de lanzamiento y eventos GitHub de cola de fusión. 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.

   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'

Cómo eliminar una cadena de herramientas mediante la interfaz de usuario de la consola

1. En la consola IBM Cloud, haga clic en el icono de menú > Automatización de la plataforma > Cadenas de herramientas.
2. En la página Cadenas de herramientas, pulse una cadena de herramientas para abrir su página Visión general. Como alternativa, en la página Detalles de la app, pulse el nombre de la cadena de herramientas.
3. En la sección "Pipelines de entrega", busque el pipeline que desea eliminar.
4. Haga clic en el icono Menú de esa canalización y en la opción Eliminar.
5. Confirma la eliminación haciendo clic en Eliminar en el cuadro de diálogo.

Cómo eliminar un Delivery Pipeline mediante 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.

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. Aplica el plan de ejecución de Terraform. Terraform realiza todas las acciones necesarias para suprimir la interconexión.

   terraform apply
   

Activación de la canalización a través de la línea de comandos o la API

Puede activar una canalización desde la línea de comandos utilizando la CLI de IBM Cloud o mediante una llamada directa a la API a través de curl.