Amazon non CodeCatalyst è più aperta a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta [Come migrare da CodeCatalyst](migration.md). 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à. # L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger Puoi avviare automaticamente un CodeCatalyst flusso di lavoro Amazon con un trigger del flusso di lavoro. Un *trigger del flusso* di lavoro, o semplicemente un *trigger*, ti consente di avviare automaticamente un flusso di lavoro quando si verificano determinati eventi, ad esempio l'invio di un codice. Potresti voler configurare i trigger per evitare agli sviluppatori di software di dover avviare manualmente il flusso di lavoro tramite la CodeCatalyst console. Puoi utilizzare tre tipi di trigger: + **Push**: un trigger di invio di codice provoca l'avvio di un flusso di lavoro ogni volta che viene premuto un commit. + **Pull request**: un trigger di pull request fa sì che un workflow venga avviato ogni volta che una pull request viene creata, rivista o chiusa. + **Pianificazione**: un trigger di pianificazione fa sì che l'esecuzione di un workflow venga avviata in base a una pianificazione definita dall'utente. Prendi in considerazione l'utilizzo di un trigger di pianificazione per eseguire le build notturne del tuo software in modo che la build più recente sia pronta per essere utilizzata dagli sviluppatori il mattino successivo. Puoi utilizzare i trigger push, pull request e schedule da soli o in combinazione nello stesso flusso di lavoro. I trigger sono facoltativi: se non ne configuri nessuno, puoi avviare un flusso di lavoro solo manualmente. **Suggerimento** Per vedere un trigger in azione, avvia un progetto con un blueprint. La maggior parte dei blueprint contiene un flusso di lavoro con un trigger. Cerca la `Trigger` proprietà nel file di definizione del flusso di lavoro del blueprint. Per ulteriori informazioni sui piani, consulta [Creare un progetto con un blueprint](projects-create.md#projects-create-console-template). **Topics** + [ # Esempi: trigger nei flussi di lavoro ](workflows-add-trigger-examples.md) + [ # Linee guida per l'utilizzo di trigger e filiali ](workflows-add-trigger-considerations.md) + [ # Aggiungere trigger ai flussi di lavoro ](workflows-add-trigger-add.md) # Esempi: trigger nei flussi di lavoro Gli esempi seguenti mostrano come aggiungere diversi tipi di trigger in un file di definizione del CodeCatalyst flusso di lavoro Amazon. Per ulteriori informazioni sui trigger, consulta [L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger](workflows-add-trigger.md). **Topics** + [ ## Esempio: un semplice pulsante di attivazione tramite codice ](#workflows-add-trigger-examples-push-simple) + [ ## Esempio: un semplice trigger «push to main» ](#workflows-add-trigger-examples-push-main) + [ ## Esempio: un semplice trigger di pull request ](#workflows-add-trigger-examples-pull-simple) + [ ## Esempio: un semplice trigger di pianificazione ](#workflows-add-trigger-examples-schedule-simple) + [ ## Esempio: un trigger con una pianificazione e rami ](#workflows-add-trigger-examples-schedule-branches) + [ ## Esempio: un trigger con una pianificazione, un push e rami ](#workflows-add-trigger-examples-schedule-push-branches) + [ ## Esempio: un grilletto con trazione e ramificazioni ](#workflows-add-trigger-examples-pull-branches) + [ ## Esempio: un trigger con pull, branch e un evento «CLOSED» ](#workflows-add-trigger-examples-push-pull-close) + [ ## Esempio: un trigger con push, branch e file ](#workflows-add-trigger-examples-push-multi) + [ ## Esempio: un trigger manuale ](#workflows-add-trigger-examples-manual) + [ ## Esempio: trigger in una configurazione con CI/CD più flussi di lavoro ](#workflows-add-trigger-usecases) ## Esempio: un semplice pulsante di attivazione tramite codice L'esempio seguente mostra un trigger che avvia un flusso di lavoro ogni volta che il codice viene inviato a *qualsiasi* ramo del repository di origine. *Quando questo trigger è attivato, CodeCatalyst avvia un flusso di lavoro eseguito utilizzando i file nel ramo verso cui state inviando il push (ovvero il ramo di destinazione).* Ad esempio, se invii un commit a`main`, CodeCatalyst avvia un flusso di lavoro eseguito utilizzando il file di definizione del flusso di lavoro e altri file di origine. `main` Come altro esempio, se si invia un commit a`feature-branch-123`, CodeCatalyst avvia un flusso di lavoro eseguito utilizzando il file di definizione del flusso di lavoro e altri file di origine. `feature-branch-123` ``` Triggers: - Type: PUSH ``` **Nota** Se desideri che l'esecuzione di un flusso di lavoro inizi solo quando esegui il push to`main`, consulta. [Esempio: un semplice trigger «push to main»](#workflows-add-trigger-examples-push-main) ## Esempio: un semplice trigger «push to main» L'esempio seguente mostra un trigger che avvia l'esecuzione di un flusso di lavoro ogni volta che il codice viene inviato al ramo, `main` e *solo* al ramo, del repository di origine. `main` ``` Triggers: - Type: PUSH Branches: - main ``` ## Esempio: un semplice trigger di pull request L'esempio seguente mostra un trigger che avvia l'esecuzione di un flusso di lavoro ogni volta che una richiesta pull viene creata o modificata nel repository di origine. Quando questo trigger è attivato, CodeCatalyst avvia un flusso di lavoro eseguito utilizzando il file di definizione del flusso di lavoro e altri file sorgente nel ramo *da* cui state estraendo (ovvero il ramo di origine). Ad esempio, se crei una richiesta pull con un ramo di origine chiamato `feature-123` e un ramo di destinazione chiamato`main`, CodeCatalyst avvia un flusso di lavoro eseguito utilizzando il file di definizione del flusso di lavoro e altri file di origine. `feature-123` ``` Triggers: - Type: PULLREQUEST Events: - OPEN - REVISION ``` ## Esempio: un semplice trigger di pianificazione L'esempio seguente mostra un trigger che avvia un flusso di lavoro eseguito a mezzanotte (UTC\$10) dal lunedì al venerdì. Quando questo trigger è attivato, CodeCatalyst avvia un singolo flusso di lavoro per ogni ramo del repository di origine che contiene un file di definizione del flusso di lavoro con questo trigger. Ad esempio, se nel repository di origine sono presenti tre rami,, `main` `release-v1``feature-123`, e ognuno di questi rami contiene un file di definizione del flusso di lavoro con il trigger seguente, CodeCatalyst avvia tre esecuzioni del flusso di lavoro: una utilizzando i file in`main`, un'altra utilizzando i file in `release-v1` e un'altra utilizzando i file in. `feature-123` ``` Triggers: - Type: SCHEDULE Expression: "0 0 ? * MON-FRI *" ``` Per altri esempi di espressioni cron che è possibile utilizzare nella `Expression` proprietà, vedere. [Expression](workflow-reference.md#workflow.triggers.expression) ## Esempio: un trigger con una pianificazione e rami L'esempio seguente mostra un trigger che avvia un flusso di lavoro eseguito ogni giorno alle 18:15 (UTC\$10). Quando questo trigger è attivato, CodeCatalyst avvia un flusso di lavoro eseguito utilizzando i file nel `main` ramo e avvia esecuzioni aggiuntive per ogni ramo che inizia con. `release-` Ad esempio, se sono presenti rami denominati`main`, `release-v1``bugfix-1`, e `bugfix-2` nel repository di origine, CodeCatalyst avvia due esecuzioni del flusso di lavoro: una utilizzando i file in esso `main` e l'altra utilizzando i file in`release-v1`. *Non* avvia le esecuzioni del flusso di lavoro per i `bugfix-1` rami `bugfix-1` and. ``` Triggers: - Type: SCHEDULE Expression: "15 18 * * ? *" Branches: - main - release\-.* ``` Per altri esempi di espressioni cron che è possibile utilizzare nella `Expression` proprietà, vedere[Expression](workflow-reference.md#workflow.triggers.expression). ## Esempio: un trigger con una pianificazione, un push e rami L'esempio seguente mostra un trigger che avvia un flusso di lavoro eseguito a mezzanotte (UTC\$10) ogni giorno e ogni volta che il codice viene inviato alla filiale. `main` In questo esempio: + L'esecuzione di un flusso di lavoro inizia ogni giorno a mezzanotte. L'esecuzione del flusso di lavoro utilizza il file di definizione del flusso di lavoro e altri file di origine presenti nel `main` ramo. + L'esecuzione di un flusso di lavoro viene inoltre avviata ogni volta che si invia un commit al `main` ramo. L'esecuzione del flusso di lavoro utilizza il file di definizione del flusso di lavoro e altri file di origine nel ramo di destinazione (`main`). ``` Triggers: - Type: SCHEDULE Expression: "0 0 * * ? *" Branches: - main - Type: PUSH Branches: - main ``` Per altri esempi di espressioni cron che è possibile utilizzare nella `Expression` proprietà, vedere[Expression](workflow-reference.md#workflow.triggers.expression). ## Esempio: un grilletto con trazione e ramificazioni L'esempio seguente mostra un trigger che avvia un flusso di lavoro ogni volta che qualcuno apre o modifica una richiesta pull con un branch di destinazione chiamato`main`. Sebbene il ramo specificato nella `Triggers` configurazione sia`main`, l'esecuzione del flusso di lavoro utilizzerà il file di definizione del flusso di lavoro e altri file di origine nel ramo di *origine* (che è il ramo *da* cui state estraendo). ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION ``` ## Esempio: un trigger con pull, branch e un evento «CLOSED» L'esempio seguente mostra un trigger che avvia l'esecuzione di un flusso di lavoro ogni volta che una richiesta pull viene chiusa su un ramo che inizia con`main`. In questo esempio: + Quando si chiude una richiesta pull con un ramo di destinazione che inizia con`main`, l'esecuzione di un workflow viene avviata automaticamente utilizzando il file di definizione del flusso di lavoro e altri file di origine nel ramo di origine (ora chiuso). + Se hai configurato il tuo repository di origine per eliminare automaticamente i branch dopo l'unione di una pull request, questi branch non avranno mai la possibilità di entrare nello `CLOSED` stato. Ciò significa che i rami uniti non attiveranno il trigger della pull request. `CLOSED` L'unico modo per attivare il `CLOSED` trigger in questo scenario è chiudere la pull request senza unirla. ``` Triggers: - Type: PULLREQUEST Branches: - main.* Events: - CLOSED ``` ## Esempio: un trigger con push, branch e file L'esempio seguente mostra un trigger che avvia l'esecuzione di un flusso di lavoro ogni volta che viene apportata una modifica al `filename.txt` file, o a qualsiasi file nella `src` directory, sul `main` ramo. Quando questo trigger è attivato, CodeCatalyst avvia un flusso di lavoro eseguito utilizzando il file di definizione del flusso di lavoro e altri file di origine nel `main` ramo. ``` Triggers: - Type: PUSH Branches: - main FilesChanged: - filename.txt - src\/.* ``` ## Esempio: un trigger manuale Per configurare un trigger manuale, omettete la `Triggers` sezione dal file di definizione del flusso di lavoro. Senza questa sezione, gli utenti sono costretti ad avviare il flusso di lavoro manualmente scegliendo il pulsante **Esegui** nella CodeCatalyst console. Per ulteriori informazioni, consulta [Avvio manuale dell’esecuzione di un flusso di lavoro](workflows-manually-start.md). ## Esempio: trigger in una configurazione con CI/CD più flussi di lavoro Questo esempio descrive come configurare i trigger quando desideri utilizzare CodeCatalyst flussi di lavoro Amazon separati per l'integrazione continua (CI) e la distribuzione continua (CD). In questo scenario, configuri due flussi di lavoro: + un **flusso di lavoro CI**: questo flusso di lavoro crea e verifica l'applicazione quando viene creata o modificata una pull request. + un **flusso di lavoro su CD**: questo flusso di lavoro crea e distribuisce l'applicazione quando viene unita una pull request. Il file di definizione del **flusso di lavoro CI** sarebbe simile al seguente: ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION Actions: BuildAction: instructions-for-building-the-app TestAction: instructions-for-test-the-app ``` Il `Triggers` codice indica di avviare un flusso di lavoro eseguito automaticamente ogni volta che uno sviluppatore di software crea una pull request (o [ne modifica una](pull-requests-update.md)) chiedendo di unire il proprio feature branch al `main` branch. CodeCatalyst avvia il flusso di lavoro eseguito utilizzando il codice sorgente nel ramo sorgente (che è il ramo delle funzionalità). Il file di definizione del **flusso di lavoro del CD** sarebbe simile al seguente: ``` Triggers: - Type: PUSH Branches: - main Actions: BuildAction: instructions-for-building-the-app DeployAction: instructions-for-deploying-the-app ``` Il `Triggers` codice indica di avviare automaticamente il flusso di lavoro quando si `main` verifica un'unione a. CodeCatalyst avvia il flusso di lavoro eseguito utilizzando il codice sorgente nel `main` ramo. # Linee guida per l'utilizzo di trigger e filiali Questa sezione descrive alcune delle linee guida principali per la configurazione di CodeCatalyst trigger Amazon che includono filiali. Per ulteriori informazioni sui trigger, consulta [L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger](workflows-add-trigger.md). + **Linea guida 1:** per i trigger di richiesta push e pull, se intendi specificare un ramo, devi specificare il ramo di destinazione (o «a») nella configurazione del trigger. Non specificare mai il ramo di origine (o «da»). Nell'esempio seguente, un push da qualsiasi ramo a `main` attiva il flusso di lavoro. ``` Triggers: - Type: PUSH Branches: - main ``` Nell'esempio seguente, una richiesta pull da qualsiasi filiale `main` attiva il flusso di lavoro. ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION ``` + **Linea guida 2:** *Per i trigger push, dopo l'attivazione del flusso di lavoro, il flusso di lavoro verrà eseguito utilizzando il file di definizione del flusso di lavoro e i file sorgente nel ramo di destinazione.* + **Linea guida 3:** Per i trigger di pull request, dopo l'attivazione del flusso di lavoro, il flusso di lavoro verrà eseguito utilizzando il file di definizione del flusso di lavoro e i file sorgente nel ramo di *origine* (anche se è stato specificato il ramo di destinazione nella configurazione del trigger). + **Linea guida 4:** Lo stesso trigger in un ramo potrebbe non essere eseguito in un altro ramo. Considerate il seguente pulsante: ``` Triggers: - Type: PUSH Branches: - main ``` Se il file di definizione del flusso di lavoro contenente questo trigger esiste in `main` e viene clonato`test`, il flusso di lavoro non verrà mai avviato automaticamente utilizzando i file in esso contenuti `test` (sebbene sia possibile avviare il flusso di lavoro *manualmente* per fare in modo che utilizzi i file in `test` esso contenuti). Consultate **la Linea guida 2** per capire perché il flusso di lavoro non verrà mai eseguito automaticamente utilizzando i file in esso contenuti. `test` Considerate anche il seguente trigger di pull request: ``` Triggers: - Type: PULLREQUEST Branches: - main Events: - OPEN - REVISION ``` Se il file di definizione del flusso di lavoro contenente questo trigger esiste in`main`, il flusso di lavoro non verrà mai eseguito utilizzando i file in`main`. (Tuttavia, se si crea un `test` ramo di`main`, il flusso di lavoro verrà eseguito utilizzando i file in`test`.) Consulta **la Linea guida 3** per capire perché. # Aggiungere trigger ai flussi di lavoro Utilizza le seguenti istruzioni per aggiungere un trigger push, pull o schedulate al tuo CodeCatalyst flusso di lavoro Amazon. Per ulteriori informazioni sui trigger, consulta [L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger](workflows-add-trigger.md). ------ #### [ Visual ] **Per aggiungere un trigger (editor visivo)** 1. Apri la CodeCatalyst console all'[indirizzo https://codecatalyst.aws/](https://codecatalyst.aws/). 1. Scegliere il progetto. 1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.** 1. Scegli il nome del tuo flusso di lavoro. Puoi filtrare in base al nome del repository o del ramo di origine in cui è definito il flusso di lavoro oppure filtrare in base al nome o allo stato del flusso di lavoro. 1. Scegli **Modifica**. 1. Scegli **Visual**. 1. Nel diagramma del flusso di lavoro, scegli la casella **Source** and **Triggers**. 1. Nel riquadro di configurazione, scegli **Aggiungi** trigger. 1. Nella finestra di dialogo **Aggiungi trigger**, fornisci le informazioni nei campi, come segue. **Tipo di trigger** Specificare il tipo di trigger. È possibile utilizzare uno dei seguenti valori: + **Push** (editor visivo) o `PUSH` (editor YAML) Un push trigger avvia l'esecuzione di un flusso di lavoro quando una modifica viene inviata all'archivio di origine. *L'esecuzione del flusso di lavoro utilizzerà i file del ramo verso cui state inviando il push (ovvero il ramo di destinazione).* + **Pull request** (editor visuale) o `PULLREQUEST` (editor YAML) Un trigger di pull request avvia un flusso di lavoro quando una pull request viene aperta, aggiornata o chiusa nel repository di origine. L'esecuzione del flusso di lavoro utilizzerà i file nel ramo *da* cui state estraendo (ovvero il ramo di origine). + **Pianificazione** (editor visivo) 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à avviato un flusso di lavoro separato per ogni ramo del repository di origine utilizzando i file del ramo. (Per limitare i rami su cui si attiva il trigger, usa il campo **Branches** (editor visivo) o la `Branches` proprietà (editor YAML).) Quando configuri un trigger di pianificazione, segui queste linee guida: + Utilizza solo un 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 per avviarli contemporaneamente. + Assicurati di configurare l'espressione cron del trigger con un tempo adeguato tra le esecuzioni. Per ulteriori informazioni, consulta [Expression](workflow-reference.md#workflow.triggers.expression). Per alcuni esempi, consulta [Esempi: trigger nei flussi di lavoro](workflows-add-trigger-examples.md). **Eventi per la pull request** Questo campo viene visualizzato solo se è stato selezionato il tipo di trigger della **richiesta Pull**. Specificate 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 una pull request** (editor visuale) o `OPEN` (editor YAML) L'esecuzione del flusso di lavoro viene avviata quando viene creata una richiesta pull. + La **pull request è chiusa** (editor visivo) o `CLOSED` (editor YAML) L'esecuzione del flusso di lavoro viene avviata quando viene chiusa una pull request. Il comportamento dell'`CLOSED`evento è complicato e può essere compreso meglio attraverso un esempio. Per ulteriori informazioni, consulta [Esempio: un trigger con pull, branch e un evento «CLOSED»](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close). + **Viene effettuata una nuova revisione per pull request** (editor visivo) o `REVISION` (editor YAML) L'esecuzione del workflow 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 di origine specificato nella pull request. Se includi l'`REVISION`evento nel trigger della pull request, puoi omettere l'`OPEN`evento, poiché `REVISION` è un superset di. `OPEN` È possibile specificare più eventi nello stesso trigger di pull request. Per alcuni esempi, consulta [Esempi: trigger nei flussi di lavoro](workflows-add-trigger-examples.md). **Pianificazione** Questo campo viene visualizzato solo se è stato selezionato il tipo di trigger **Schedule**. Specificate l'espressione cron che descrive quando desiderate che avvenga l'esecuzione 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** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/workflows-add-trigger-add.html) Quando specifichi le espressioni cron in CodeCatalyst, assicurati di seguire queste linee guida: + Specificate una singola espressione cron per trigger. `SCHEDULE` + Racchiudi l'espressione cron tra virgolette doppie (`"`) nell'editor YAML. + Specificate l'ora in UTC (Coordinated Universal Time). Altri fusi orari non sono supportati. + Configura almeno 30 minuti tra un'esecuzione e l'altra. Una cadenza più veloce non è supportata. + Specificate 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 «tutti» 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](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html) *Amazon EventBridge * User Guide. Le espressioni Cron CodeCatalyst funzionano esattamente EventBridge allo stesso modo. Per esempi di trigger di pianificazione, vedi. [Esempi: trigger nei flussi di lavoro](workflows-add-trigger-examples.md) **Rami** e schema delle **filiali** (Facoltativo) Specificate i rami nel vostro repository di origine monitorati dal trigger per sapere quando avviare l'esecuzione di un flusso di lavoro. È possibile utilizzare modelli regex per definire i nomi delle filiali. Ad esempio, utilizzare per `main.*` abbinare tutti i rami che iniziano con`main`. I rami da specificare sono diversi a seconda del tipo di trigger: + Per un trigger push, specifica i rami verso cui stai eseguendo *il* push, ovvero i rami di *destinazione*. Verrà avviata un'esecuzione del flusso di lavoro per ramo corrispondente, utilizzando i file nel ramo corrispondente. Esempi: `main.*`, `mainline` + **Per un trigger di pull request, specifica i rami verso cui stai inviando il push, ovvero i rami di destinazione.** Verrà avviata un'esecuzione del flusso di lavoro per 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 con) `v1-` + 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 ramo corrispondente, utilizzando il file di definizione del flusso di lavoro e i file sorgente nel ramo corrispondente. Esempi: `main.*`, `version\-1\.0` **Nota** Se *non* specifichi i rami, il trigger monitora tutti i rami nel tuo repository di origine e avvierà un flusso di lavoro eseguito utilizzando il file di definizione del flusso di lavoro e i file sorgente in: Il ramo verso cui stai eseguendo il push (*per i* trigger push). Per ulteriori informazioni, consulta [Esempio: un semplice pulsante di attivazione tramite codice](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple). Il ramo *da* cui stai prelevando (per i trigger di pull request). Per ulteriori informazioni, consulta [Esempio: un semplice trigger di pull request](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple). Tutte le filiali (per i trigger di pianificazione). Verrà avviata un'unica esecuzione del flusso di lavoro per ramo nel repository di origine. Per ulteriori informazioni, consulta [Esempio: un semplice trigger di pianificazione](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple). Per ulteriori informazioni su rami e trigger, consulta. [Linee guida per l'utilizzo di trigger e filiali](workflows-add-trigger-considerations.md) Per ulteriori esempi, consulta [Esempi: trigger nei flussi di lavoro](workflows-add-trigger-examples.md). **File modificati** Questo campo viene visualizzato solo se è stato selezionato il tipo di trigger di **richiesta **Push o Pull****. Specificate i file o le cartelle nell'archivio di origine monitorati dal trigger per sapere quando avviare l'esecuzione di un flusso di lavoro. È possibile utilizzare espressioni regolari per abbinare i nomi o i percorsi dei file. Per alcuni esempi, consulta [Esempi: trigger nei flussi di lavoro](workflows-add-trigger-examples.md). 1. (Facoltativo) Scegliete **Convalida per convalidare** il codice YAML del flusso di lavoro prima di eseguire il commit. 1. **Scegliete **Commit**, inserite un messaggio di commit e scegliete nuovamente Commit.** ------ #### [ YAML ] **Per aggiungere un trigger (editor YAML)** 1. [Apri la CodeCatalyst console all'indirizzo https://codecatalyst.aws/.](https://codecatalyst.aws/) 1. Scegliere il progetto. 1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.** 1. Scegli il nome del tuo flusso di lavoro. Puoi filtrare in base al nome del repository o del ramo di origine in cui è definito il flusso di lavoro oppure filtrare in base al nome o allo stato del flusso di lavoro. 1. Scegli **Modifica**. 1. Scegli **YAML**. 1. Aggiungi una `Triggers` sezione e le proprietà sottostanti usando l'esempio seguente come guida. Per ulteriori informazioni, consultare [Triggers](workflow-reference.md#triggers-reference) nella [Definizione YAML del flusso di lavoro](workflow-reference.md). Un trigger con codice potrebbe avere il seguente aspetto: ``` Triggers: - Type: PUSH Branches: - main ``` Un trigger di pull request potrebbe avere il seguente aspetto: ``` Triggers: - Type: PULLREQUEST Branches: - main.* Events: - OPEN - REVISION - CLOSED ``` Un trigger di pianificazione potrebbe essere simile al seguente: ``` Triggers: - Type: SCHEDULE Branches: - main.* # Run the workflow at 1:15 am (UTC+0) every Friday until the end of 2023 Expression: "15 1 ? * FRI 2022-2023" ``` Per altri esempi di espressioni cron che è possibile utilizzare nella `Expression` proprietà, vedere[Expression](workflow-reference.md#workflow.triggers.expression). Per altri esempi di trigger push, pull request e schedule, vedi. [Esempi: trigger nei flussi di lavoro](workflows-add-trigger-examples.md) 1. (Facoltativo) Scegliete **Convalida per convalidare** il codice YAML del flusso di lavoro prima di eseguire il commit. 1. **Scegliete **Commit**, inserite un messaggio di commit e scegliete nuovamente Commit.** ------