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à. # 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.