Gestione delle pipeline Tekton

Configurazione di un Delivery Pipeline per Tekton utilizzando la console

1. Dalla pagina Panoramica della tua toolchain, nella scheda Delivery pipelines, fai clic su Delivery Pipeline per aprire la pagina Panoramica di Tekton Delivery Pipeline.

2. Fai clic su Settings. Nella sezione Definitions, completa le seguenti attività:

   a. Specifica il repository Git e l'URL che contiene la definizione della pipeline Tekton e le risorse correlate. Se il tuo repository non è disponibile, ritorna alla pagina di panoramica della toolchain e aggiungilo.

   b. Seleziona il ramo all'interno del tuo repository Git che desideri utilizzare oppure immetti una tag.

   c. Specifica il percorso alla tua definizione di pipeline all'interno del repository Git. Puoi fare riferimento a una specifica definizione all'interno dello stesso repository. Puoi anche aggiungere più repository di definizioni, se sono integrati con la toolchain.

   d. Salva le tue modifiche.

   La definizione della pipeline viene aggiornata automaticamente.

   Il limite della dimensione della definizione di pipeline calcolata è 1 MB. Se riscontri degli errori quando salvi o esegui la tua pipeline, potresti dover ridurre la dimensione della tua definizione di pipeline o suddividerla in più pipeline.

3. Nella sezione Worker, seleziona il nodo di lavoro condiviso gestito da IBM o il nodo di lavoro privato che vuoi utilizzare per eseguire la tua pipeline Tekton. Per ulteriori informazioni sui nodi di lavoro privati, vedi Gestione dei nodi di lavoro privati Delivery Pipeline.

   Il nodo di lavoro privato deve essere definito nella stessa toolchain della tua pipeline Tekton.

4. Nella sezione Proprietà dell'ambiente, fare clic su Aggiungi e selezionare un tipo di proprietà per definire la propria proprietà dell'ambiente. Ad esempio, puoi definire una proprietà API_KEY che passa una chiave API che viene utilizzata da tutti gli script nella pipeline per accedere alle risorse IBM Cloud. Puoi aggiungere i seguenti tipi di proprietà:

   • Enumerazione: una chiave proprietà con un valore che può essere selezionato da un elenco di opzioni definito dall'utente.
   • Valore protetto: una chiave di proprietà con un valore su una sola riga, protetta tramite crittografi AES-128. Questo valore viene visualizzato utilizzando il carattere asterisco. In alternativa, puoi fare clic sull'icona della chiave per selezionare un segreto da un'integrazione del vault (come IBM Key Protect), se tale strumento è disponibile nella tua toolchain.
   • Valore di testo: una chiave di proprietà con un valore di testo che può essere a riga singola o a più righe. In precedenza, i valori a più righe erano supportati da un tipo di proprietà Area di testo separato.
   • Integrazione dello strumento: una chiave di proprietà con un valore che viene risolto in fase di runtime da un'integrazione dello strumento toolchain. Per default, il valore è una rappresentazione di stringa JSON dell'integrazione dello strumento. È possibile richiamare un campo o un sottoinsieme specifico dell'oggetto fornendo un valore per il filtro JSON facoltativo. Ad esempio, se si seleziona un'integrazione GitHub e si specifica il filtro JSON parameters.repo_url, il valore riflette il URL del repo Git configurato nell'integrazione dello strumento quando la risorsa PipelineRun viene eseguita.

   Puoi accedere a queste proprietà nelle tue risorse di pipeline Tekton. Per ulteriori informazioni su queste proprietà, vedi Risorse e ambiente delle pipeline Tekton.

   Le proprietà possono essere bloccate per evitare che vengano sovrascritte. Il tentativo di sovrascrivere una proprietà bloccata al runtime determinerà il rifiuto della richiesta di esecuzione. Le proprietà bloccate non vengono visualizzate per impostazione predefinita nel pannello laterale di esecuzione ma possono essere visualizzate solo in lettura abilitando l'opzione 'Mostra tutte le proprietà'.

5. Fare clic su Salva.

6. Nella pagina Panoramica pipeline, fare clic su Aggiungi per creare un trigger, selezionare il tipo di trigger da aggiungere e associare il trigger a un listener eventi. L'elenco dei listener di eventi disponibili contiene i listener definiti nel repository del codice della pipeline.

   I trigger si basano sulle definizioni dei trigger di Tekton. Git I trigger repo utilizzano il listener di eventi a cui sono associati per estrarre informazioni dal payload dell'evento in arrivo e creare risorse dell Kubernetes. Queste risorse sono applicate a una risorsa PipelineRun Tekton.

   Le esecuzioni pipeline attivate vengono eseguite simultaneamente a meno che non si configuri il trigger per serializzare le esecuzioni utilizzando l'opzione Limit concurrent runs. Quando questa opzione è abilitata, è possibile limitare il numero di esecuzioni simultanee che possono essere avviate da questo trigger. Ad esempio, se il limite massimo è impostato a 1, viene eseguita una sola pipeline alla volta per questo trigger e le altre vengono accodate in uno stato di "Attesa". Un massimo di 20 esecuzioni (5 se si utilizzano IBM Managed Workers) vengono messe in coda in stato di attesa prima che le richieste successive vengano automaticamente annullate. Per impostazione predefinita, tutti i trigger temporizzati sono limitati a un'esecuzione simultanea quando si utilizzano IBM i Managed Workers

   Quando un trigger supera il suo limite di esecuzioni contemporanee, le nuove esecuzioni della pipeline vengono poste in uno stato di "Attesa" fino a quando non si rende disponibile la capacità. Se lo si desidera, è possibile modificare questo comportamento in modo che solo la corsa più recente sia in stato di "Attesa" e che le altre vengano automaticamente annullate. Ciò può essere utile, ad esempio, per Git i trigger se si desidera eseguire il build solo del commit più recente quando vengono attivati più processi in un breve lasso di tempo. Per abilitare questa funzione, nel pannello di configurazione del trigger è disponibile la levetta "Limita a un'esecuzione in attesa", che può essere impostata anche tramite API utilizzando la proprietà limit_waiting_runs (vedere la documentazione API ). Si noti che questa impostazione si applica solo alle corse in stato di "Attesa" e non influisce sulle corse attive.

   I trigger manuali vengono eseguiti quando fai clic sul pulsante della pipeline Run e selezioni il trigger.

   I trigger di repository Git vengono eseguiti quando si verifica il tipo di evento Git specificato per il repository e il ramo Git specificati.

   Puoi accedere al payload del webhook distribuito a un trigger Git dalle tue risorse della pipeline Tekton. Sebbene i campi esatti siano specifici per il repository, la sintassi generale per il payload del webhook è $(event.payloadFieldName). Prima di poter creare un webhook, è necessario autorizzare l'accesso Git amministrativo per l'integrazione Git corrispondente. Per autorizzare l'accesso Git come amministratore, configurare e salvare nuovamente Git l'integrazione.

   I trigger temporizzati vengono eseguiti a un orario prestabilito, definito dal valore CRON. L'espressione CRON per i trigger temporizzati si basa sulla sintassi crontab di UNIX ed è costituita da una sequenza di cinque campi relativi a data e ora: minute, hour, day of the month, month e day of the week. Questi campi sono separati da spazi nel formato X X X X X. La frequenza massima per un trigger a tempo è una volta ogni cinque minuti. I seguenti esempi mostrano stringhe che utilizzano varie frequenze temporizzate.

   • */5 * * * *- Il trigger viene eseguito ogni 5 minuti.
   • 0 * * * * - Il trigger viene eseguito all'inizio di ogni ora.
   • 0 9 * 1 MON-FRI - Il trigger viene eseguito alle 9:00 di ogni settimana di gennaio.
   • 0 * * NOV,DEC 1 - Il trigger viene eseguito ogni ora dei lunedì di novembre e dicembre.

   I trigger webhook generici vengono eseguiti quando una richiesta POST configurata con l'impostazione come segreto passa all'URL webhook generico. I trigger di webhook generici forniscono un URL webhook univoco per le richieste POST.

   Poiché l'interfaccia PipelineRun utente non nasconde i valori generici del payload del webhook nella sezione dedicata al payload dell'evento, non includere dati sensibili nel payload. Invece, proteggi tutti i dati richiesti da un webhook generico utilizzando le proprietà trigger, come le password o i segreti della chiave API.

   Puoi proteggere i trigger di webhook generici per lavorare con Git, un webhook in uscita Slack, un webhook Artifactory e altro ancora utilizzando uno qualsiasi dei seguenti metodi:

   • Corrispondenze di token per confrontare il token salvato e il token passato all'interno della richiesta POST. Le origini di token supportate includono un'intestazione, una query o un payload. Le corrispondenze di token sono utilizzate dai webhook GitLab e dai webhook in uscita Slack.
   • Il digest di payload corrisponde alla messa a confronto della firma e dell'hash generati dal payload di cui è stato eseguito il digest utilizzando il digest esadecimale HMAC con un token salvato. Le origini di firma supportate potrebbero includere un'intestazione, una query o un payload. Gli utenti devono specificare un algoritmo di digest. Le corrispondenze di digest di payload sono utilizzate dai webhook GitHub.
   • La convalida dell'attività Tekton richiede che gli utenti convalidino la richiesta webhook nelle loro attività Tekton.

   Specifica i seguenti valori per utilizzare i trigger webhook generici con i webhook GitHub:

   • Protezione: Payload Digest Matches
   • Origine della firma: Header
   • Nome della chiave di intestazione: X-Hub-Signature
   • Algoritmo di digest: sha1.

   Specifica i seguenti valori per utilizzare i trigger webhook generici con i webhook GitLab:

   • Protezione: Token Matches
   • Origine token: Header
   • Nome della chiave di intestazione: X-Gitlab-Token

   Specifica i seguenti valori per utilizzare i trigger webhook generici con i webhook in uscita Slack:

   • Protezione: Token Matches
   • Origine token: Payload
   • Nome proprietà JSON / chiave modulo: token

   Il seguente esempio mostra come utilizzare il comando curl con un webhook generico protetto con una regola Token Matches:

   

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

   Per ottenere i valori di payload nella definizione della pipeline, specificare un parametro Triggerbinding con un valore derivato dall'evento:

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

   Salva le tue modifiche.

   Inoltre, i trigger webhook generici supportano il passaggio di proprietà nel corpo della richiesta webhook. Ciò consente di sovrascrivere le proprietà per il sito PipelineRun che viene attivato dal webhook, o di passare proprietà aggiuntive che integrano le proprietà della pipeline/trigger utilizzate nel sito PipelineRun.

   Se si desidera inserire dati sensibili nelle proprietà del payload, come password o segreti delle chiavi API, è necessario utilizzare il tipo di proprietà SECURE per tali proprietà, in modo che non vengano visualizzate in chiaro nell'interfaccia utente.

   Inoltre, nel corpo della richiesta può essere passata una descrizione opzionale che descrive il PipelineRun che viene attivato e che viene visualizzata nell'interfaccia utente quando si visualizzano i dettagli di PipelineRun in un browser.

   L'esempio seguente mostra come utilizzare il comando curl con un webhook generico, passando una proprietà text, una proprietà secure e una descrizione:

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

Configurazione dei trigger Delivery Pipeline per le pipeline Tekton

È possibile configurare i trigger per le pipeline Tekton in base a vari eventi nel proprio repo Git. Filtrare i trigger Git utilizzando le seguenti opzioni:

• Ramo: Attiva la pipeline per un ramo specifico del repo selezionato quando si verifica l'evento specificato.
• Schema: Attiva la pipeline in base a una corrispondenza globale con i tag e i nomi dei rami nel repo selezionato quando si verifica l'evento specificato.
• Filtro CEL: Attiva la pipeline quando l'evento corrisponde al filtro Common Expression Language (CEL) fornito.

Utilizzare le opzioni Ramo e Modello per specificare eventi come 'commit push, 'pull request opened, 'updated o 'closed. Inoltre, è possibile specificare gli eventi delle richieste di pull, modificando l'opzione Includi eventi delle richieste di pull in bozza per consentire o saltare i trigger della pipeline per le richieste di pull in bozza. Allo stesso modo, si può specificare se si vuole consentire l'attivazione della pipeline per le richieste di pull da repository biforcati, usando la levetta Includi eventi di richiesta di pull da biforcazioni. Inoltre, è possibile selezionare l'opzione Filtri etichetta per attivare il filtraggio basato sulle etichette delle richieste di pull secondo i criteri definiti dall'utente nella tabella dei filtri.

L'opzione di filtro CEL supporta casi d'uso più avanzati, come la corrispondenza con altri campi del payload dell'evento. Questa opzione supporta gli eventi push, tutti gli eventi pull request, gli eventi issue, gli eventi commenti issue, gli eventi release e gli eventi GitHub merge queue. Questa opzione è disponibile anche come funzione opzionale sul trigger Webhook generico per fornire un filtraggio degli eventi basato sul payload 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'

Eliminazione di una catena di strumenti tramite l'interfaccia utente della console

1. Dalla console IBM Cloud, fare clic sull'icona Menu Automazione piattaforma > Catene di strumenti.
2. Nella pagina Toolchains, fai clic su una toolchain per aprirne la pagina di panoramica. In alternativa, nella pagina App details nella tua applicazione, fai clic sul nome della toolchain.
3. Nella sezione "Pipeline di consegna", individuare la pipeline che si desidera eliminare.
4. Fare clic sull'icona del menu per quella pipeline e fare clic sull'opzione Elimina.
5. Confermare l'eliminazione facendo clic su Elimina nella finestra di dialogo.

Eliminazione di un Delivery Pipeline con l'API

1. Ottieni un token di connessione IAM. In alternativa, se stai utilizzando un SDK, ottieni una chiave API IAM e imposta le opzioni client utilizzando le variabili di ambiente.

   export CD_TEKTON_PIPELINE_APIKEY={api_key}
   

2. Determina la regione e l'ID della toolchain a cui vuoi aggiungere l'integrazione dello strumento DevOps Insights.

3. Elimina la pipeline.

   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 seguente tabella elenca e descrive ciascuna delle variabili utilizzate nel passo precedente.

Eliminazione di un Delivery Pipeline con Terraform

1. Individua il file Terraform (ad esempio main.tf) che contiene il blocco resource per la pipeline esistente.

   Il resource nel seguente esempio descrive una pipeline esistente.

   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. Rimuovi i blocchi ibm_cd_toolchain_tool_pipeline e ibm_cd_tekton_pipeline resource dal file Terraform.

3. Inizializza la CLI Terraform, se necessario.

   terraform init
   

4. Creare un piano di esecuzione Terraform. Questo piano riepiloga tutte le azioni che devono essere eseguite per eliminare la pipeline.

   terraform plan
   

5. Applicare il piano di esecuzione di Terraform. Terraform intraprende tutte le azioni richieste per eliminare la pipeline.

   terraform apply
   

Attivazione della pipeline tramite riga di comando o API

È possibile attivare una pipeline dalla riga di comando, utilizzando la CLI di IBM Cloud o effettuando una chiamata diretta all'API tramite curl.