View a markdown version of this page

Definizione YAML del flusso di lavoro - Amazon CodeCatalyst

Amazon non CodeCatalyst è più aperto a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta Come migrare da CodeCatalyst.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Definizione YAML del flusso di lavoro

Di seguito è riportata la documentazione di riferimento per il file di definizione del flusso di lavoro.

Un file di definizione del flusso di lavoro è un file YAML che descrive il flusso di lavoro. Per impostazione predefinita, il file è archiviato in una ~/.codecatalyst/workflows/ cartella nella radice del repository di origine. Il file può avere un'estensione .yml o .yaml e l'estensione deve essere minuscola.

Per creare e modificare il file di definizione del flusso di lavoro, puoi utilizzare un editor come vim oppure puoi utilizzare l'editor visuale della CodeCatalyst console o l'editor YAML. Per ulteriori informazioni, consulta Utilizzo degli editor visivi e YAML della CodeCatalyst console.

Nota

La maggior parte delle proprietà YAML che seguono hanno elementi dell'interfaccia utente corrispondenti nell'editor visuale. Per cercare un elemento dell'interfaccia utente, usate Ctrl+F. L'elemento verrà elencato con la proprietà YAML associata.

Esempio di file di definizione del flusso di lavoro

Di seguito è riportato un esempio di un semplice file di definizione del flusso di lavoro. Include alcune proprietà di primo livello, una Triggers sezione e una Actions sezione con due azioni: Build eTest. Per ulteriori informazioni, consulta Informazioni sul file di definizione del flusso di lavoro.

Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main Actions: Build: Identifier: aws/build@v1 Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: docker build -t MyApp:latest . Test: Identifier: aws/managed-test@v1 DependsOn: - Build Inputs: Sources: - WorkflowSource Configuration: Steps: - Run: npm install - Run: npm run test

Linee guida e convenzioni sulla sintassi

Questa sezione descrive le regole di sintassi per il file di definizione del flusso di lavoro, nonché le convenzioni di denominazione utilizzate in questa documentazione di riferimento.

Linee guida sulla sintassi YAML

Il file di definizione del flusso di lavoro è scritto in YAML e segue le specifiche YAML 1.1, quindi tutto ciò che è consentito in quella specifica è consentito anche nel flusso di lavoro YAML. Se non conosci YAML, ecco alcune linee guida rapide per assicurarti di fornire un codice YAML valido.

  • Case-sensitivity: il file di definizione del flusso di lavoro fa distinzione tra maiuscole e minuscole, quindi assicurati di utilizzare la combinazione di maiuscole e minuscole mostrata in questa documentazione.

  • Caratteri speciali: consigliamo di utilizzare virgolette o doppie virgolette per racchiudere i valori delle proprietà che includono uno dei seguenti caratteri speciali: { } [],,,,*,#, & ?|,-,,,,,,,=,!, % @ : ` ,

    Se non si includono le virgolette, i caratteri speciali elencati in precedenza potrebbero essere interpretati in modo imprevisto.

  • Nomi delle proprietà: i nomi delle proprietà (al contrario dei valori delle proprietà) sono limitati a caratteri alfanumerici (a-z,, 0-9) A-Z, trattini (-) e trattini bassi (_). Gli spazi non sono consentiti. Non è possibile utilizzare virgolette o doppie virgolette per abilitare caratteri speciali e spazi nei nomi delle proprietà.

    Non consentito:

    'My#Build@action'

    My#Build@action

    My Build Action

    Consentito:

    My-Build-Action_1

  • Codici di escape: se il valore della tua proprietà include codici di escape (ad esempio, \n or\t), segui queste linee guida:

    • Usa le virgolette singole per restituire il codice di escape come stringa. Ad esempio'my string \n my string', restituisce la stringamy string \n my string.

    • Usa le virgolette doppie per analizzare il codice di escape. Ad esempio"my string \n my new line", restituisce:

      my string my new line
  • Commenti: prefigura i commenti con#.

    Esempio:

    Name: MyWorkflow # This is a comment. SchemaVersion: 1.0
  • Triplo trattino (---): non utilizzare --- nel codice YAML. CodeCatalyst ignora tutto ciò che segue. ---

Convenzioni di denominazione

In questa guida, utilizziamo i termini proprietà e sezione per fare riferimento agli elementi principali di un file di definizione del flusso di lavoro.

  • Una proprietà è qualsiasi elemento che include i due punti (:). Ad esempio, nel seguente frammento di codice, tutte le proprietà seguenti sono:Name,SchemaVersion, RunMode TriggersType, e. Branches

  • Una sezione è qualsiasi proprietà con proprietà secondarie. Nel seguente frammento di codice, c'è una sezione. Triggers

    Nota

    In questa guida, le «sezioni» vengono talvolta chiamate «proprietà» e viceversa, a seconda del contesto.

    Name: MyWorkflow SchemaVersion: 1.0 RunMode: QUEUED Triggers: - Type: PUSH Branches: - main

Top-level proprietà

Di seguito è riportata la documentazione di riferimento per le proprietà di primo livello nel file di definizione del flusso di lavoro.

# Name Name: workflow-name # Schema version SchemaVersion: 1.0 # Run mode RunMode: QUEUED|SUPERSEDED|PARALLEL # Compute Compute: ... # Triggers Triggers: ... # Actions Actions: ...

Nome

(Obbligatorio)

Nome del flusso di lavoro. Il nome del flusso di lavoro viene visualizzato nell'elenco dei flussi di lavoro e indicato nelle notifiche e nei registri. Il nome del flusso di lavoro e il nome del file di definizione del flusso di lavoro possono corrispondere oppure è possibile denominarli in modo diverso. I nomi dei flussi di lavoro non devono necessariamente essere univoci. I nomi dei flussi di lavoro sono limitati a caratteri alfanumerici (a-z, A-Z, 0-9), trattini (-) e trattini bassi (_). Gli spazi non sono consentiti. Non è possibile utilizzare le virgolette per abilitare caratteri speciali e spazi nei nomi dei flussi di lavoro.

Interfaccia utente corrispondente: editor/Workflow proprietà visive/ nome del flusso di lavoro

SchemaVersion

(Obbligatorio)

La versione dello schema della definizione del flusso di lavoro. Attualmente, l'unico valore valido è 1.0.

Interfaccia utente corrispondente: nessuna

RunMode

(Facoltativo)

Come CodeCatalyst gestisce più esecuzioni. È possibile utilizzare uno dei seguenti valori:

  • QUEUED— Le esecuzioni multiple vengono messe in coda ed eseguite una dopo l'altra. Puoi avere fino a 50 corse in coda.

  • SUPERSEDED— Le corse multiple vengono messe in coda ed eseguite una dopo l'altra. Una coda può avere una sola esecuzione, quindi se due esecuzioni finiscono insieme nella stessa coda, la corsa successiva sostituisce (sostituisce) la corsa precedente e quella precedente viene annullata.

  • PARALLEL— Le esecuzioni multiple avvengono contemporaneamente.

Se questa proprietà viene omessa, l'impostazione predefinita èQUEUED.

Per ulteriori informazioni, consulta Configurazione del comportamento di accodamento delle esecuzioni.

Interfaccia utente corrispondente: modalità editor/Workflow properties/Advanced visiva/Run

Calcolo

(Facoltativo)

Il motore di calcolo utilizzato per eseguire le azioni del flusso di lavoro. È possibile specificare l'elaborazione a livello di flusso di lavoro o a livello di azione, ma non entrambi. Se specificata a livello di flusso di lavoro, la configurazione di calcolo si applica a tutte le azioni definite nel flusso di lavoro. A livello di flusso di lavoro, puoi anche eseguire più azioni sulla stessa istanza. Per ulteriori informazioni, consulta Condivisione dell'elaborazione tra le azioni.

Per ulteriori informazioni sull'elaborazione, vedereConfigurazione delle immagini di calcolo e di runtime.

Interfaccia utente corrispondente: nessuna

Name: MyWorkflow SchemaVersion: 1.0 ... Compute: Type: EC2 | Lambda Fleet: fleet-name SharedInstance: true | false

Tipo

(Compute/Type)

(Obbligatorio se Compute è impostato)

Il tipo di motore di calcolo. È possibile utilizzare uno dei seguenti valori:

  • EC2 (editor visuale) o EC2 (editor YAML)

    Ottimizzato per la flessibilità durante l'esecuzione delle azioni.

  • Lambda (editor visuale) o Lambda (editor YAML)

    Velocità di avvio delle azioni ottimizzate.

Per ulteriori informazioni sui tipi di calcolo, consulta Tipi di calcolo.

Interfaccia utente corrispondente: tipo editor/Workflow properties/Advanced visivo/di elaborazione

Parco istanze

(Compute/Fleet)

(Facoltativo)

Specifica la macchina o il parco macchine che eseguirà il flusso di lavoro o le azioni del flusso di lavoro. Con le flotte on-demand, quando un'azione viene avviata, il flusso di lavoro fornisce le risorse necessarie e le macchine vengono distrutte al termine dell'azione. Esempi di flotte su richiesta:,. Linux.x86-64.Large Linux.x86-64.XLarge Per ulteriori informazioni sulle flotte su richiesta, vedere. On-demand proprietà della flotta

Con le flotte con provisioning, configuri un set di macchine dedicate per eseguire le azioni del flusso di lavoro. Queste macchine rimangono inattive, pronte a elaborare le azioni immediatamente. Per ulteriori informazioni sulle flotte predisposte, vedere. Proprietà del parco istanze con provisioning

Se Fleet viene omesso, l'impostazione predefinita è. Linux.x86-64.Large

Per ulteriori informazioni sulle flotte di calcolo, vedere. Flotte di calcolo

Interfaccia utente corrispondente: visual editor/Workflow properties/Advanced/Compute fleet

SharedInstance

(Compute/SharedInstance)

(Facoltativo)

Specifica la funzionalità di condivisione dell'elaborazione per le tue azioni. Con la condivisione dell'elaborazione, le azioni in un flusso di lavoro vengono eseguite sulla stessa istanza (immagine dell'ambiente di runtime). È possibile utilizzare uno dei seguenti valori:

  • TRUEsignifica che l'immagine dell'ambiente di runtime è condivisa tra le azioni del flusso di lavoro.

  • FALSEsignifica che viene avviata e utilizzata un'immagine dell'ambiente di runtime separata per ogni azione in un flusso di lavoro, quindi non è possibile condividere risorse come artefatti e variabili senza una configurazione aggiuntiva.

Per ulteriori informazioni sulla condivisione dell'elaborazione, vedere. Condivisione dell'elaborazione tra le azioni

Interfaccia utente corrispondente: nessuna

Triggers

(Facoltativo)

Una sequenza di uno o più trigger per questo flusso di lavoro. Se non viene specificato un trigger, è necessario avviare manualmente il flusso di lavoro.

Per ulteriori informazioni sui trigger, consulta L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger.

Interfaccia utente corrispondente: editor/workflow diagramma visivo/trigger

Name: MyWorkflow SchemaVersion: 1.0 ... Triggers: - Type: PUSH Branches: - branch-name FilesChanged: - folder1/file - folder2/ - Type: PULLREQUEST Events: - OPEN - CLOSED - REVISION Branches: - branch-name FilesChanged: - file1.txt - Type: SCHEDULE # Run the workflow at 10:15 am (UTC+0) every Saturday Expression: "15 10 ? * 7 *" Branches: - branch-name

Tipo

(Triggers/Type)

(Obbligatorio se Triggers è impostato)

Specifica il tipo di trigger. È possibile utilizzare uno dei seguenti valori:

  • Push (editor visuale) o PUSH (editor YAML)

    Un push trigger avvia l'esecuzione di un flusso di lavoro quando una modifica viene inviata al repository di origine. L'esecuzione del flusso di lavoro utilizzerà i file nel ramo a cui stai inviando il push (ovvero il ramo di destinazione).

  • Pull request (editor visuale) o PULLREQUEST (editor YAML)

    Un trigger di richiesta pull avvia l'esecuzione di un flusso di lavoro quando una richiesta pull viene aperta, aggiornata o chiusa nel repository di origine. L'esecuzione del flusso di lavoro utilizzerà i file presenti nel ramo da cui stai prelevando (ovvero il ramo di origine).

  • Pianificazione (editor visuale) o SCHEDULE (editor YAML)

    Un trigger di pianificazione avvia l'esecuzione del flusso di lavoro in base a una pianificazione definita da un'espressione cron specificata dall'utente. Verrà avviata un'esecuzione del flusso di lavoro separata per ogni ramo nel repository di origine utilizzando i file del ramo. (Per limitare i rami su cui si attiva il trigger, usa il campo Branches (editor visuale) o la Branches proprietà (editor YAML).)

    Quando configuri un trigger di pianificazione, segui queste linee guida:

    • Utilizza un solo trigger di pianificazione per flusso di lavoro.

    • Se hai definito più flussi di lavoro nel tuo CodeCatalyst spazio, ti consigliamo di programmarne non più di 10 in modo che vengano avviati contemporaneamente.

    • Assicurati di configurare l'espressione cron del trigger con un tempo adeguato tra le esecuzioni. Per ulteriori informazioni, consulta Expression.

Per alcuni esempi, consulta Esempi: trigger nei flussi di lavoro.

Interfaccia utente corrispondente: tipo editor/workflow diagram/Triggers visuale/Trigger

Eventi

(Triggers/Events)

(Obbligatorio se il trigger Type è impostato suPULLREQUEST)

Specifica il tipo di eventi di pull request che avvieranno l'esecuzione di un flusso di lavoro. Di seguito sono riportati i valori validi:

  • Viene creata la pull request (editor visuale) o OPEN (editor YAML)

    L'esecuzione del flusso di lavoro viene avviata quando viene creata una richiesta pull.

  • La richiesta pull è chiusa (editor visuale) o CLOSED (editor YAML)

    L'esecuzione del flusso di lavoro viene avviata alla chiusura di una richiesta pull. Il comportamento dell'CLOSEDevento è complicato e si comprende meglio con un esempio. Per ulteriori informazioni, consulta Esempio: un trigger con pull, branch e un evento «CLOSED».

  • La nuova revisione viene effettuata tramite pull request (editor visuale) o REVISION (editor YAML)

    L'esecuzione del flusso di lavoro viene avviata quando viene creata una revisione di una pull request. La prima revisione viene creata quando viene creata la pull request. Dopodiché, viene creata una nuova revisione ogni volta che qualcuno invia un nuovo commit al ramo sorgente specificato nella richiesta pull. Se includi l'REVISIONevento nel trigger della richiesta pull, puoi omettere l'OPENevento, poiché REVISION è un superset di. OPEN

Puoi specificare più eventi nello stesso trigger di pull request.

Per alcuni esempi, consulta Esempi: trigger nei flussi di lavoro.

Interfaccia utente corrispondente: visual editor/workflow diagram/Triggers/Events for pull request

Rami

(Triggers/Branches)

(Facoltativo)

Specifica i rami del tuo repository di origine che il trigger monitora per sapere quando avviare l'esecuzione di un flusso di lavoro. Puoi usare modelli regex per definire i nomi dei tuoi rami. Ad esempio, usa per main.* abbinare tutti i rami che iniziano conmain.

I rami da specificare sono diversi a seconda del tipo di trigger:

  • Per un push trigger, specifica i rami verso i quali stai effettuando il push, ovvero i rami di destinazione. Verrà avviata un'esecuzione del flusso di lavoro per ogni ramo corrispondente, utilizzando i file nel ramo corrispondente.

    Esempi: main.*, mainline

  • Per attivare una richiesta pull, specifica le filiali verso cui stai inviando il push, ovvero le filiali di destinazione. Verrà avviata un'esecuzione del flusso di lavoro per ogni ramo corrispondente, utilizzando il file di definizione del flusso di lavoro e i file di origine nel ramo di origine (non nel ramo corrispondente).

    Esempi:main.*,mainline, v1\-.* (corrisponde ai rami che iniziano conv1-)

  • Per un trigger di pianificazione, specifica i rami che contengono i file che desideri vengano utilizzati dall'esecuzione pianificata. Verrà avviata un'esecuzione del flusso di lavoro per ogni ramo corrispondente, utilizzando il file di definizione del flusso di lavoro e i file di origine nel ramo corrispondente.

    Esempi: main.*, version\-1\.0

Nota

Se non specifichi i rami, il trigger monitora tutti i rami nel repository di origine e avvia un'esecuzione del flusso di lavoro utilizzando il file di definizione del flusso di lavoro e i file sorgente in:

Per ulteriori informazioni su branch e trigger, consulta. Linee guida per l'utilizzo di trigger e filiali

Per ulteriori esempi, consulta Esempi: trigger nei flussi di lavoro.

Interfaccia utente corrispondente: visual editor/workflow diagram/Triggers/Branches

FilesChanged

(Triggers/FilesChanged)

(Facoltativo se il trigger Type è impostato suPUSH, oPULLREQUEST. Non supportato se il trigger Type è impostato suSCHEDULE.

Specifica i file o le cartelle nel tuo repository di origine che il trigger monitora per sapere quando avviare l'esecuzione di un flusso di lavoro. È possibile utilizzare espressioni regolari per abbinare nomi o percorsi di file.

Per alcuni esempi, consulta Esempi: trigger nei flussi di lavoro.

Interfaccia utente corrispondente: visual editor/workflow diagram/Triggers/Files changed

Expression

(Triggers/Expression)

(Obbligatorio se il trigger Type è impostato suSCHEDULE)

Specifica l'espressione cron che descrive quando desideri che si verifichino le esecuzioni del flusso di lavoro pianificato.

Le espressioni cron CodeCatalyst utilizzano la seguente sintassi a sei campi, in cui ogni campo è separato da uno spazio:

minutes hours days-of-month month days-of-week year

Esempi di espressioni cron

Minuti Ore Giorni del mese Mese Giorni della settimana Anno Significato

0

0

?

*

MON-FRI

*

Esegue un flusso di lavoro a mezzanotte (UTC+0) dal lunedì al venerdì.

0

2

*

*

?

*

Esegue un flusso di lavoro alle 2:00 (UTC+0) ogni giorno.

15

22

*

*

?

*

Esegue un flusso di lavoro alle 22:15 (UTC+0) ogni giorno.

0/30

22-2

?

*

SAT-SUN

*

Esegue un flusso di lavoro ogni 30 minuti dal sabato alla domenica tra le 22:00 del giorno di inizio e le 2:00 del giorno successivo (UTC+0).

45

13

L

*

?

2023-2027

Esegue un flusso di lavoro alle 13:45 (UTC+0) dell'ultimo giorno del mese tra gli anni 2023 e 2027 inclusi.

Quando specifichi le espressioni cron in CodeCatalyst, assicurati di seguire queste linee guida:

  • Specifica una singola espressione cron per trigger. SCHEDULE

  • Racchiudi l'espressione cron tra virgolette doppie (") nell'editor YAML.

  • Specifica l'ora in Coordinated Universal Time (UTC). Gli altri fusi orari non sono supportati.

  • Configura almeno 30 minuti tra le esecuzioni. Una cadenza più veloce non è supportata.

  • Specifica il days-of-week campo days-of-month o, ma non entrambi. Se si specifica un valore o un asterisco (*) in uno dei campi, è necessario utilizzare un punto interrogativo (?) nell'altro. L'asterisco significa «tutto» e il punto interrogativo significa «qualsiasi».

Per altri esempi di espressioni cron e informazioni sui caratteri jolly come?, e *L, consulta il riferimento alle espressioni Cron nella Amazon User Guide. EventBridge Le espressioni Cron entrano EventBridge e CodeCatalyst funzionano esattamente allo stesso modo.

Per esempi di trigger di pianificazione, vedere. Esempi: trigger nei flussi di lavoro

Interfaccia utente corrispondente: visual editor/workflow diagram/Triggers/Schedule

Azioni

Una sequenza di una o più azioni per questo flusso di lavoro. CodeCatalyst supporta diversi tipi di azioni, ad esempio le azioni di compilazione e test, che offrono diversi tipi di funzionalità. Ogni tipo di azione ha:

  • una Identifier proprietà che indica l'ID univoco e codificato dell'azione. Ad esempio, aws/build@v1 identifica l'azione di compilazione.

  • una Configuration sezione che contiene proprietà specifiche dell'azione.

Per ulteriori informazioni su ciascun tipo di azione, vedereTipi di operazione. L'Tipi di operazioneargomento contiene collegamenti alla documentazione per ogni azione.

Di seguito è riportato il riferimento YAML per le azioni e i gruppi di azioni nel file di definizione del flusso di lavoro.

Name: MyWorkflow SchemaVersion: 1.0 ... Actions: action-or-gate-name: Identifier: identifier Configuration: ... #Action groups action-group-name: Actions: ...

action-or-gate-name

(Actions/action-or-gate-name)

(Obbligatorio)

Sostituisci action-name con un nome a cui vuoi dare all'azione. I nomi delle azioni devono essere univoci all'interno del flusso di lavoro e includere solo caratteri alfanumerici, trattini e caratteri di sottolineatura. Per ulteriori informazioni sulle regole di sintassi, vedere. Linee guida sulla sintassi YAML

Per ulteriori informazioni sulle procedure di denominazione delle azioni, incluse le restrizioni, vedere. action-or-gate-name

Interfaccia utente corrispondente: editor visivo/ /scheda action-name Configurazione/ Nome azione o Nome visualizzato dell'azione

nome-gruppo di azioni

(Actions/action-group-name)

(Facoltativo)

Un gruppo di azioni contiene una o più azioni. Il raggruppamento delle azioni in gruppi di azioni consente di mantenere organizzato il flusso di lavoro e consente inoltre di configurare le dipendenze tra diversi gruppi.

Sostituisci action-group-name con un nome che vuoi dare al gruppo di azioni. I nomi dei gruppi di azioni devono essere univoci all'interno del flusso di lavoro e includere solo caratteri alfanumerici, trattini e caratteri di sottolineatura. Per ulteriori informazioni sulle regole di sintassi, vedere. Linee guida sulla sintassi YAML

Per ulteriori informazioni sui gruppi di azioni, vedereRaggruppamento delle azioni in gruppi d'azione.

Interfaccia utente corrispondente: nessuna