Gestione delle pipeline Tekton
Tekton Pipelines è un progetto open source che può essere utilizzato per configurare ed eseguire pipeline di Continuous Integration e Continuous Delivery all'interno di un cluster Kubernetes. Le pipeline Tekton sono definite nei file yaml, che sono di norma archiviati in un repository (repo) Git.
Tekton fornisce una serie di estensioni di risorse personalizzate a Kubernetes per definire le pipeline. Le seguenti risorse di pipeline Tekton di base sono incluse in queste estensioni:
Risorsa | Descrizione |
---|---|
Task |
Definisce una serie di passi di build quali la compilazione del codice, l'esecuzione di test e la creazione e la distribuzione di immagini. |
TaskRun |
Istanzia un'attività per l'esecuzione con input, output e parametri di esecuzione specifici. È possibile avviare l'attività da sola o come parte di una pipeline. |
Pipeline |
Definisce la serie di attività che forma una pipeline. |
PipelineRun |
Istanzia una pipeline per l'esecuzione con input, output e parametri di esecuzione specifici. |
È possibile usufruire delle seguenti funzioni quando si utilizzano Tekton Pipelines:
- Native del cloud: le pipeline Tekton vengono eseguite su Kubernetes, utilizzano i cluster Kubernetes come tipo di prima classe e utilizzano i contenitori come loro blocchi di costruzione.
- Disaccoppiate: puoi utilizzare una singola pipeline per eseguire la distribuzione a qualsiasi cluster Kubernetes. Puoi eseguire le attività che formano una pipeline in isolamento. Puoi anche commutare le risorse (quali i repository Git) tra le esecuzioni di pipeline.
- Con tipo: puoi commutare le implementazioni per specifici tipi di risorse, come ad esempio le immagini.
Il progetto Tekton Pipelines è un release beta. Devi aggiornare la tua pipeline con ciascuna nuova versione di Tekton. Per ulteriori informazioni sull'ultima versione di Tekton, consultare la sezione https://github.com/tektoncd/pipeline/releases.
IBM Cloud® Continuous Delivery fornisce due tipi di delivery pipeline che puoi utilizzare per creare, verificare e distribuire le tue applicazioni.
- Classic: le delivery pipeline classiche vengono create graficamente, con lo stato integrato nel diagramma della pipeline. Queste pipeline possono essere eseguite su nodi di lavoro condivisi nel cloud oppure su nodi di lavoro privati che vengono eseguiti sul tuo cluster Kubernetes.
- Tekton: le delivery pipeline Tekton vengono create nei file yaml che definiscono le pipeline come una serie di risorse Kubernetes. È possibile modificare questi file yaml per cambiare il comportamento di una pipeline. Le pipeline Tekton possono essere eseguite sui nodi di lavoro privati che vengono eseguiti sul tuo cluster. Possono essere eseguite anche sui nodi di lavoro gestiti da IBM sul cloud pubblico. L'integrazione con Tekton fornisce una dashboard che può essere utilizzata per visualizzare lo stato delle esecuzioni della pipeline Tekton e attivare nuove esecuzioni. Fornisce anche i meccanismi per specificare i trigger della pipeline, le definizioni della pipeline, il nodo di lavoro su cui viene eseguita la pipeline e le proprietà della pipeline.
Entrambi i tipi di pipeline isolano i lavori o i passi tra loro mediante l'esecuzione in contenitori separati oppure utilizzando un'immagine a tua scelta. Le pipeline Classic e Tekton esistono entrambe in una toolchain e dipendono da questa per aggiungere altre integrazioni di strumenti utilizzati nel processo di compilazione, test e distribuzione.
Il 20 novembre 2020, Dockerhub ha introdotto la limitazione della frequenza delle immagini anonime. Questa modifica potrebbe influire sugli utenti che stanno eseguendo le attività che fanno riferimento alle immagini ospitate da Dockerhub. Si consiglia di utilizzare un registro alternativo, come IBM Cloud Container Registry.
Prerequisiti
Prima di aggiungere ed eseguire una pipeline Tekton, assicurati di avere le seguenti risorse correttamente posizionate:
-
Una toolchain che contiene le seguenti integrazioni dello strumento:
- Un'integrazione dello strumento del repository (come ad esempio l'integrazione dello strumento GitHub) che contiene il tuo codice di pipeline Tekton, compreso un file yaml Tekton. Trovate esempi di pipeline e definizioni di task su GitHub. Per ulteriori informazioni su come iniziare a utilizzare le pipeline Tekton, vedere Pipeline Tekton.
- Facoltativo. Se non utilizzi il nodo di lavoro della pipeline condiviso predefinito, puoi utilizzare un'integrazione dello strumento di nodo di lavoro privato Delivery Pipeline che fa riferimento al tuo cluster Kubernetes. Per ulteriori informazioni sui nodi di lavoro privati, vedi Installazione dei nodi di lavoro privati Delivery Pipeline.
-
CLI IBM Cloud installata localmente.
-
kubectl installato localmente.
-
Un cluster Kubernetes (versione 1.22 o superiore) come un cluster IBM Cloud® Kubernetes Service.
La toolchain e l'integrazione dello strumento del nodo di lavoro privato Delivery Pipeline devono essere nella stessa regione.
Creazione di un Delivery Pipeline per Tekton utilizzando la console
Quando configuri un'integrazione dello strumento Delivery Pipeline, puoi selezionare il tipo di pipeline che vuoi creare.
-
Se non si dispone di una catena di strumenti, selezionare un modello per creare una catena di strumenti. A seconda del template che utilizzi, possono essere disponibili diversi campi. Rivedi i valori di campo predefiniti e se necessario, modifica queste impostazioni.
-
Se si dispone di una catena di strumenti e vi si sta aggiungendo questa integrazione di strumenti, dalla console IBM Cloud, fare clic sull'icona Menu
Platform Automation > Toolchains. Nella pagina Toolchain, fare clic sulla toolchain per aprire la relativa pagina Panoramica. In alternativa, nella pagina della panoramica della tua applicazione, nella scheda di fornitura continua, fai clic su View toolchain. Fai quindi clic su Overview.
-
Aggiungi l'integrazione della pipeline di fornitura alla tua toolchain:
a. Fai clic su Add tool.
b. Nella sezione Integrazioni strumento, fai clic su Delivery Pipeline.
-
Specifica un nome per la tua nuova pipeline.
-
Seleziona Tekton per creare una Delivery Pipeline Tekton. È possibile visualizzare l'output delle esecuzioni della pipeline Tekton su un cluster Kubernetes definito, con il supporto per la configurazione dei repository delle definizioni della pipeline, dei trigger della pipeline, del luogo di esecuzione della pipeline e di semplici segreti.
-
Se hai intenzione di utilizzare la tua pipeline per distribuire un'interfaccia utente, seleziona la casella di spunta Mostra applicazioni nel menu Visualizza applicazioni. Tutte le applicazioni create dalla tua pipeline vengono visualizzate nell'elenco Visualizza applicazione nella pagina di panoramica della toolchain.
-
Fai clic su Create Integration per aggiungere la Delivery Pipeline alla tua toolchain.
Configurazione di un Delivery Pipeline per Tekton utilizzando la console
-
Dalla pagina Panoramica della tua toolchain, nella scheda Delivery pipelines, fai clic su Delivery Pipeline per aprire la pagina Panoramica di Tekton Delivery Pipeline.
-
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.
-
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.
-
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 di una sola riga che è protetto con la crittografia 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 risorsaPipelineRun
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à'.
-
Fare clic su Salva.
-
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 degli ascoltatori di eventi disponibili contiene gli ascoltatori definiti nel repo del codice della pipeline.
I trigger sono basati sulle definizioni di trigger Tekton. Git i trigger di repo usano l'ascoltatore di eventi a cui sono mappati per estrarre informazioni dal payload dell'evento in arrivo e creare risorse 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 su 1, solo una pipeline eseguita per questo trigger viene eseguita alla volta e tutte le altre vengono accodate in uno stato di attesa. Un massimo di 20 esecuzioni (5 se si utilizzano i Managed Worker IBM ) vengono accodate in uno stato di attesa prima che le richieste successive vengano annullate automaticamente. Per impostazione predefinita, tutti i trigger temporizzati sono limitati a un'esecuzione concorrente quando si utilizzano i Managed Worker IBMI 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, devi autorizzare l'accesso amministratore Git per l'integrazione Git corrispondente. Per autorizzare l'accesso di amministratore Git, configurare e salvare nuovamente l'integrazione Git.I trigger temporizzati vengono eseguiti a un'ora programmata, definita dal valore CRON. L'espressione CRON per i trigger temporizzati si basa sulla sintassi crontab UNIX ed è una sequenza di cinque campi di data e ora:
minute
,hour
,day of the month
,month
, Eday of the week
. Questi campi sono separati da spazi nel formatoX 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 utente PipelineRun non nasconde i valori del payload webhook generico nella sezione del payload eventi, 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
:generico di webhook*Esempio generico di 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 delle richieste di pull, gli eventi dei problemi, gli eventi dei commenti ai problemi e gli eventi di rilascio. Questa opzione è disponibile anche come funzione opzionale sul trigger Webhook generico per fornire un filtraggio degli eventi basato sul payload del webhook.
Panoramica del CEL
CEL è un linguaggio di espressione potente e flessibile, progettato per valutare condizioni ed eseguire convalide in modo conciso e leggibile. CEL è ideale per i casi d'uso che richiedono una logica condizionale complessa, come il filtraggio degli eventi.
Nella pipeline Tekton, l'opzione CEL è stata introdotta per fornire un filtraggio degli eventi più potente e flessibile. Il payload del webhook viene valutato rispetto all'espressione CEL fornita dall'utente. Se l'espressione CEL ha come
risultato true
, l'esecuzione della pipeline viene attivata.
In CEL sono supportate le seguenti funzioni:
- Operatori aritmetici (
+
,-
,*
,/
,%
) - Operatori di confronto (
=
,!=
,<
,>
,<=
,>=
) - Operatori logici (
&&
,||
) - Operatori di stringa (
contains
,matches
,startsWith
,endsWith
) - Operatori di raccolta (
in
,!in
) - Variabili (fare riferimento alle variabili direttamente con i loro nomi)
- Letterali (supporta letterali come stringhe, numeri, booleani e null)
CEL include le seguenti estensioni per fornire ulteriori funzionalità al linguaggio CEL di base:
Sets extension
per supportare operazioni di set avanzate e fornire maggiore flessibilità nel filtraggio degli eventi. Per ulteriori informazioni su questa estensione, vedere Insiemi.matchesGlob
per garantire la compatibilità durante la conversione del campo modello esistente nella nuova opzione di filtro CEL. L'operatore nativo CELmatches
è consigliato per una corrispondenza di espressioni regolari più avanzata.
Per ulteriori informazioni su CEL, consultare la documentazione CEL.
Conversione in CEL
Completare i passaggi seguenti per convertire la selezione di filtraggio eventi esistente in un'espressione CEL:
-
Modificare il trigger Git che si vuole convertire.
-
Nella sezione Attivazione su, selezionare l'opzione Filtro CEL.
filtro I seguenti elementi vengono convertiti automaticamente in un'espressione CEL equivalente:
- Ramo o modello
- Eventi, come
commit push
,pull request opened
,updated
eclosed
- Includere eventi di bozza di richiesta di pull
- Includere gli eventi delle richieste di pull dai fork
- Filtri etichette
caption-side=bottom" L'espressione CEL generata viene scritta in un campo dell'area di testo, che può essere modificato secondo le necessità.
Poiché non esistono filtri sui trigger Webhook generici per la conversione, la conversione in un filtro CEL si applica solo ai trigger Git.
Se si salva l'attivazione con l'opzione CEL selezionata, questa sostituisce gli eventi precedentemente selezionati con l'espressione CEL. Se si passa all'opzione Ramo o Modello dopo aver salvato l'opzione Filtro CEL, le selezioni di eventi precedenti non vengono salvate. La conversione dall'opzione CEL all'opzione Ramo o Modello non è supportata.
Esempi di espressione CEL
Gli esempi seguenti sono espressioni CEL comuni per ciascuno dei tipi di Git supportati: GitHub
, GitLab
e BitBucket
. È possibile copiare e modificare questi esempi per soddisfare le proprie esigenze.
GitHub esempi:
Viene eseguito quando una richiesta di pull viene aperta o aggiornata rispetto al ramo specificato:
header['x-github-event'] == 'pull_request' &&
(body.action == 'opened' || body.action == 'synchronize') &&
body.pull_request.base.ref == 'main'
Viene eseguito quando un commit viene spinto nel ramo specificato:
header['x-github-event'] == 'push' && body.ref == 'refs/heads/main'
Esegue quando un commit viene spinto nel ramo specificato, ma lo salta quando il messaggio di commit contiene una stringa specifica:
header['x-github-event'] == 'push' &&
body.ref == 'refs/heads/main' &&
!body.head_commit.message.contains("skip run")
Eseguito quando un commento contenente la stringa specificata viene aggiunto a una richiesta di pull:
header['x-github-event'] == 'issue_comment' &&
body.action == 'created' && has(body.issue.pull_request) &&
body.comment.body.contains('/lgtm')
Viene eseguito quando viene creato un problema con l'etichetta specificata:
header['x-github-event'] == 'issues' &&
body.action == 'opened' &&
body.issue.labels.exists(label, label.name == 'urgent')
GitLab esempi:
Viene eseguito quando una richiesta di unione viene aperta o aggiornata rispetto al ramo specificato:
header['x-gitlab-event'] == 'Merge Request Hook' &&
(body.object_attributes.action == 'open' || body.object_attributes.action == 'update') &&
body.object_attributes.target_branch == 'main'
Viene eseguito quando un commit viene spinto nel ramo specificato:
header['x-gitlab-event'] == 'Push Hook' && body.ref == 'refs/heads/main'
Esegue quando un commit viene spinto nel ramo specificato, ma lo salta quando il messaggio di commit contiene una stringa specifica:
header['x-gitlab-event'] == 'Push Hook' &&
body.ref == 'refs/heads/main' &&
!body.object_attributes.last_commit.message("skip run")
Viene eseguito quando un commento contenente la stringa specificata viene aggiunto a una richiesta di unione:
header['x-gitlab-event'] == 'Note Hook' &&
body.object_attributes.noteable_type == 'MergeRequest' &&
body.object_attributes.action == 'create' &&
body.object_attributes.note.contains('/lgtm')
Viene eseguito quando viene creato un problema con l'etichetta specificata:
header['x-gitlab-event'] == 'Issue Hook' &&
(body.object_attributes.action == 'open') &&
body.object_attributes.labels.exists(label, label.name == 'urgent')
BitBucket esempi:
Viene eseguito quando una richiesta di pull viene aperta o aggiornata rispetto al ramo specificato:
(header['x-event-key'] == 'pullrequest:created' || header['x-event-key'] == 'pullrequest:updated') &&
body.pullrequest.destination.branch.name == 'main'
Viene eseguito quando un commit viene spinto nel ramo specificato:
header['x-event-key'] == 'repo:push' && body.push.changes[0].new.name == 'main'
Esegue quando un commit viene spinto nel ramo specificato, ma lo salta quando il messaggio di commit contiene una stringa specifica:
header['x-event-key'] == 'repo:push' &&
body.push.changes[0].new.name == 'main' &&
!body.push.changes[0].commits[0].message("skip run")
Eseguito quando un commento contenente la stringa specificata viene aggiunto a una richiesta di pull:
header['x-event-key'] == 'pullrequest:comment_created' &&
body.comment.content.raw.contains('/lgtm')
Viene eseguito quando viene creato un problema con l'etichetta specificata:
header['x-event-key'] == 'issue:created' &&
body.issue.kind == 'bug'
Filtri
I filtri consentono agli utenti di affinare le richieste di pull in base a criteri specifici. Il campo filtro supporta attualmente la specificazione di etichette nelle richieste di pull, controllando così l'esecuzione della pipeline in base alla loro presenza o assenza. Tuttavia, non attiva una pipeline quando le etichette vengono aggiunte o rimosse; piuttosto, verifica le etichette della PR prima di consentire l'esecuzione della pipeline.
Come funziona:
- Se si verifica un evento PR (come l'aggiunta di un nuovo commit), la pipeline controlla le etichette della PR.
- Se il PR soddisfa le condizioni dell'etichetta (ad esempio, ha l'etichetta "approvato"), la pipeline viene eseguita.
- Se la PR non soddisfa le condizioni di etichetta, la pipeline non verrà eseguita.
Configurazione di esempio
La schermata seguente mostra un esempio in cui il trigger è configurato per le etichette "approvato" e "rivisto".
- La pipeline PR viene attivata solo se sono presenti entrambe le etichette.
- Se manca una delle due etichette, la pipeline non verrà eseguita.

Controllo del carico utile dell'evento
Quando si scrivono espressioni CEL per il filtraggio degli eventi, è necessario comprendere la struttura e il contenuto del payload del webhook rispetto al quale verrà valutata l'espressione. È possibile ispezionare il payload di una sessione esistente dalla pagina dei dettagli della sessione Pipeline.
Per visualizzare il payload dell'evento, accedere alla pagina dei dettagli dell'esecuzione della pipeline e fare clic su Mostra contesto. È possibile visualizzare il payload del webhook grezzo che ha attivato l'esecuzione della pipeline e confermare i campi pertinenti per le espressioni CEL in modo che corrispondano alle condizioni desiderate.
Creazione di un Delivery Pipeline per Tekton con l'API
-
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}
-
Determina la regione e l'ID della toolchain a cui vuoi aggiungere l'integrazione dello strumento Delivery Pipeline.
-
Aggiungi l'integrazione dello strumento Delivery Pipeline alla toolchain.
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 seguente tabella elenca e descrive ciascuna delle variabili utilizzate nel passo precedente.
Variabili per aggiungere l'integrazione dello strumento Delivery Pipeline con l'API Variabile Descrizione {region}
La regione in cui si trova la toolchain, ad esempio us-south
.{tool_integration_name}
Un nome per l'integrazione dello strumento, ad esempio ci-pipeline
.{toolchain_id}
L'ID della toolchain a cui aggiungere l'integrazione dello strumento. {iam_token}
Un token portatore IAM valido. -
Configura Delivery Pipeline per utilizzare i nodi di lavoro gestiti pubblici nelle regioni specificate.
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 seguente tabella elenca e descrive ciascuna delle variabili utilizzate nel passo precedente.
Variabili per configurare la Delivery Pipeline con l'API Variabile Descrizione {region}
La regione in cui si trova la toolchain, ad esempio us-south
.{pipeline_id}
L'ID della pipeline restituita dal passo precedente in cui è stata creata l'integrazione dello strumento pipeline. {iam_token}
Un token portatore IAM valido.
Per ulteriori informazioni sull'API Delivery Pipeline, consulta la Documentazione API.
Creazione di un Delivery Pipeline per Tekton con Terraform
-
Per installare la CLI Terraform e configurare il plug-in del provider IBM Cloud per Terraform, segui l'esercitazione per Introduzione a Terraform su IBM Cloud®.
-
Creare un file di configurazione di Terraform chiamato
main.tf
. In questo file, aggiungere la configurazione per creare una pipeline utilizzando il linguaggio di configurazione HashiCorp. Per ulteriori informazioni sull'utilizzo di questa lingua di configurazione, consultare la documentazione Terraform.Una pipeline deve appartenere a una toolchain. Puoi anche creare toolchain utilizzando Terraform.
Il seguente esempio crea una toolchain e una pipeline utilizzando le risorse Terraform specificate.
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 }
Per ulteriori informazioni relative alle
ibm_cd_toolchain_tool_pipeline
e alle risorseibm_cd_tekton_pipeline
, consultare i dettagli di riferimento dell'argomento nella documentazione del registro Terraform. -
Inizializza la CLI Terraform, se necessario.
terraform init
-
Creare un piano di esecuzione Terraform. Questo piano riepiloga tutte le azioni che devono essere eseguite per creare una toolchain.
terraform plan
-
Applicare il piano di esecuzione di Terraform. Terraform prende tutte le azioni richieste per creare la toolchain.
terraform apply
Visualizzazione di un Delivery Pipeline per Tekton
Puoi visualizzare una pipeline utilizzando l'IU della console, con l'API o con Terraform.
Visualizzazione di un Delivery Pipeline utilizzando la console
La pagina Panoramica di Tekton Delivery Pipeline visualizza una tabella vuota finché non viene aggiunto almeno un trigger. Dopo che le esecuzioni della pipeline Tekton si verificano (manualmente o come risultato di eventi esterni), la tabella
visualizza i dati sulle esecuzioni recenti associate a ogni trigger nella pipeline. Ogni riga mostra le informazioni su un singolo trigger e visualizza un grafico delle esecuzioni recenti associate a tale trigger. Vengono visualizzate anche
informazioni come l'esito positivo o negativo di tali esecuzioni e l'ora in cui si è verificata l'esecuzione più recente. È anche possibile eseguire azioni per ciascun trigger: eseguire il trigger manualmente, contrassegnarlo come preferito,
modificare il trigger, abilitarlo o disabilitarlo o eliminarlo. È anche possibile fare clic su uno degli elementi nel grafico per esaminare i dettagli di tale singolo PipelineRun
. In alternativa, puoi fare clic su un nome trigger
per aprire la pagina PipelineRuns per ogni PipelineRun
associato a tale trigger. Sono disponibili anche informazioni correlate come lo stato, il trigger e la durata di ogni PipelineRun
.
Le esecuzioni delle pipeline possono essere in uno qualsiasi di questi stati:
- Pending:
PipelineRun
è obbligatorio. - Running:
PipelineRun
è in esecuzione sul cluster. - Succeeded:
PipelineRun
completato correttamente sul cluster. - Failed:
PipelineRun
non riuscito. Riesamina il file di log per l'esecuzione per determinare la causa. - Queued:
PipelineRun
è accettato per l'elaborazione e viene eseguito quando c'è disponibilità di capacità di nodo di lavoro. - Waiting:
PipelineRun
è in attesa di essere accodato. - Cancelled:
PipelineRun
è stato annullato dal sistema o dall'utente. Il sistema annulla unPipelineRun
quando il numero di corse in attesa supera il limite consentito. - Error:
PipelineRun
contiene degli errori che impediscono l'applicazione sul cluster. Per ulteriori informazioni sulla causa dell'errore, vedi i dettagli dell'esecuzione.
Per informazioni dettagliate su un'esecuzione selezionata, fare clic su qualsiasi riga nella tabella per visualizzare la definizione Task
e i passi in ciascuna definizione PipelineRun
. Puoi anche visualizzare lo stato,
i log e i dettagli di ogni definizione e passo di Task
e lo stato complessivo della definizione PipelineRun
.
Il periodo di conservazione per PipelineRuns e i relativi log dipende dal piano selezionato per l'istanza del servizio Continuous Delivery. I gasdotti Tekton nell'ambito del piano Professional vengono mantenuti per un anno. Le pipeline Tekton
nel piano Lite vengono conservate per 30 giorni. Per conservare qualsiasi PipelineRuns
oltre il periodo di conservazione, nella sezione PipelineRuns, seleziona Azioni> Scarica** per scaricare un file .zip.
Visualizzazione di un Delivery Pipeline con l'API
-
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}
-
Ottenere i dati della pipeline.
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 seguente tabella elenca e descrive ciascuna delle variabili utilizzate nel passo precedente.
Variabile | Descrizione |
---|---|
{region} |
La regione in cui si trova la pipeline, ad esempio us-south . |
{pipeline_id} |
L'ID della pipeline che si desidera visualizzare. |
{iam_token} |
Un token portatore IAM valido. |
Visualizzazione di un Delivery Pipeline con Terraform
-
Individua il file Terraform (ad esempio
main.tf
) che contiene il bloccoresource
per la pipeline esistente. -
Aggiungere un blocco
output
al file Terraform, se non contiene già un blocco.Il
resource
nel seguente esempio descrive una pipeline esistente. Il bloccooutput
indica a Terraform di emettere gli attributi della risorsa specificata.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 }
Per ulteriori informazioni relative alle
ibm_cd_toolchain_tool_pipeline
e alle risorseibm_cd_tekton_pipeline
, consultare i dettagli di riferimento dell'argomento nella documentazione del registro Terraform. -
Inizializza la CLI Terraform, se necessario.
terraform init
-
Applicare il piano di esecuzione Terraform con l'opzione
refresh-only
. Terraform aggiorna il proprio stato e visualizza gli attributi della risorsa della pipeline.terraform apply -refresh-only -auto-approve
Eliminazione di un Delivery Pipeline con l'API
-
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}
-
Determina la regione e l'ID della toolchain a cui vuoi aggiungere l'integrazione dello strumento DevOps Insights.
-
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.
Variabile | Descrizione |
---|---|
{region} |
La regione in cui si trova la toolchain, ad esempio us-south . |
{toolchain_id} |
L'ID della toolchain contenente la pipeline da eliminare. |
{pipeline_id} |
L'ID della pipeline che si vuole eliminare. |
{iam_token} |
Un token portatore IAM valido. |
Eliminazione di un Delivery Pipeline con Terraform
-
Individua il file Terraform (ad esempio
main.tf
) che contiene il bloccoresource
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 }
-
Rimuovi i blocchi
ibm_cd_toolchain_tool_pipeline
eibm_cd_tekton_pipeline
resource
dal file Terraform. -
Inizializza la CLI Terraform, se necessario.
terraform init
-
Creare un piano di esecuzione Terraform. Questo piano riepiloga tutte le azioni che devono essere eseguite per eliminare la pipeline.
terraform plan
-
Applicare il piano di esecuzione di Terraform. Terraform intraprende tutte le azioni richieste per eliminare la pipeline.
terraform apply
Visualizzazione dei dettagli per un pod TaskRun
Per visualizzare le informazioni sul pod Kubernetes sottostante per uno specifico TaskRun
, fai clic sul nome Task
e quindi su Pod.
Puoi visualizzare i dettagli per il pod e tutti gli eventi correlati riportati dal nodo di lavoro. Queste informazioni possono essere utili per il debug di errori specifici o per determinare dove viene impiegato il tempo durante un'esecuzione.
Ulteriori informazioni sulle pipeline e le risorse Tekton
Per saperne di più sulle pipeline Tekton, consultare le pagine Tekton: A Modern Approach to Continuous Delivery e IBM Cloud Continuous Delivery Tekton Pipelines Tools and Resources.
Per ulteriori informazioni sulle attività Tekton a cui puoi fare riferimento nelle tue pipeline, consulta Open Toolchain Tekton Catalog. Questo repository GitHub contiene una serie di attività che puoi riutilizzare nelle tue pipeline Tekton.