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à.
# Esecuzione di un workflow
Per *esecuzione* si intende una singola iterazione di un flusso di lavoro. Durante un'esecuzione, CodeCatalyst esegue le azioni definite nel file di configurazione del flusso di lavoro e restituisce i log, gli artefatti e le variabili associati.
*È possibile avviare un'esecuzione manualmente o automaticamente, tramite un trigger del flusso di lavoro.* Un esempio di attivazione del flusso di lavoro potrebbe essere uno sviluppatore di software che invia un commit alla filiale principale.
Puoi anche interrompere manualmente un flusso di lavoro eseguito a metà dell'elaborazione se lo hai avviato per errore.
Se più esecuzioni del flusso di lavoro vengono avviate all'incirca nello stesso momento, è possibile configurare il modo in cui si desidera che queste esecuzioni vengano messe in coda. Puoi utilizzare il comportamento di accodamento predefinito, in cui le esecuzioni vengono messe in coda una dopo l'altra nell'ordine in cui sono state avviate, oppure puoi fare in modo che un'esecuzione successiva sostituisca (o «sostituisca») una precedente per velocizzare l'esecuzione. È inoltre possibile configurare le esecuzioni del flusso di lavoro in modo che avvengano in parallelo, in modo che nessuna esecuzione debba attendere altre esecuzioni.
Dopo aver avviato l'esecuzione di un workflow, manualmente o automaticamente, puoi visualizzare lo stato dell'esecuzione e altri dettagli. Ad esempio, puoi vedere quando è stato avviato, da chi è stato avviato e se è ancora in esecuzione.
**Topics**
+ [Avvio manuale dell’esecuzione di un flusso di lavoro](workflows-manually-start.md)
+ [L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger](workflows-add-trigger.md)
+ [Configurazione dei trigger solo manuali](workflows-manual-only.md)
+ [Arresto dell'esecuzione di un flusso di lavoro](workflows-stop.md)
+ [Garantire l'esecuzione di un flusso di lavoro](workflows-gates.md)
+ [Richiesta di approvazioni per l'esecuzione del flusso di lavoro](workflows-approval.md)
+ [Configurazione del comportamento di accodamento delle esecuzioni](workflows-configure-runs.md)
+ [Memorizzazione nella cache dei file tra le esecuzioni del workflow](workflows-caching.md)
+ [Visualizzazione dello stato e dei dettagli dell'esecuzione del flusso di lavoro](workflows-view-run.md)
# Avvio manuale dell’esecuzione di un flusso di lavoro
In Amazon CodeCatalyst, puoi avviare un flusso di lavoro eseguito manualmente dalla CodeCatalyst console.
Per ulteriori informazioni sulle esecuzioni del flusso di lavoro, consulta[Esecuzione di un workflow](workflows-working-runs.md).
**Nota**
È inoltre possibile avviare un flusso di lavoro eseguito automaticamente [configurando un trigger](workflows-add-trigger.md).
**Per avviare un flusso di lavoro, esegui manualmente**
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 **Esegui**.
# 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.**
------
# Configurazione dei trigger solo manuali
Puoi limitare un flusso di lavoro in modo che possa essere avviato solo manualmente dal tuo team utilizzando il pulsante **Esegui** nella CodeCatalyst console. Per configurare questa funzionalità, è necessario rimuovere la `Triggers` sezione nel file di definizione del flusso di lavoro. La `Triggers` sezione è inclusa per impostazione predefinita quando si crea un flusso di lavoro, ma è facoltativa e può essere rimossa.
Utilizzate le seguenti istruzioni per rimuovere la `Triggers` sezione dal file di definizione del flusso di lavoro in modo che il flusso di lavoro possa essere avviato solo manualmente.
Per ulteriori informazioni sui trigger, consulta [L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger](workflows-add-trigger.md).
Per ulteriori informazioni sull'esecuzione dei flussi di lavoro, vedere[Esecuzione di un workflow](workflows-working-runs.md).
------
#### [ Visual ]
**Per rimuovere la sezione 'Triggers' (editor visuale)**
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. Scegliete la casella **Origine** nel diagramma del flusso di lavoro.
1. In **Trigger**, scegli l'icona del cestino per rimuovere la `Triggers` sezione dal flusso di lavoro.
1. (Facoltativo) Scegli **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 rimuovere la sezione 'Triggers' (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. Trova la `Triggers` sezione e rimuovila.
1. (Facoltativo) Scegli **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.**
------
# Arresto dell'esecuzione di un flusso di lavoro
Utilizzare la procedura seguente per interrompere l'esecuzione di un flusso di lavoro in corso. Potresti voler interrompere un'esecuzione se è stata avviata accidentalmente.
Quando interrompi l'esecuzione di un flusso di lavoro, CodeCatalyst attende il completamento delle azioni in corso prima di contrassegnare l'esecuzione come **Interrotta** nella CodeCatalyst console. **Tutte le azioni che non hanno avuto la possibilità di iniziare non verranno avviate e verranno contrassegnate come Abbandonate.**
**Nota**
Se un'esecuzione è in coda (ovvero non ha azioni in corso), l'esecuzione viene interrotta immediatamente.
Per ulteriori informazioni sulle esecuzioni del flusso di lavoro, vedere. [Esecuzione di un workflow](workflows-working-runs.md)
**Per interrompere l'esecuzione di un flusso di lavoro**
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. In **Flussi di lavoro**, scegli **Esecuzioni e scegli l'esecuzione** in corso dall'elenco.
1. Scegli **Stop (Arresta)**.
# Garantire l'esecuzione di un flusso di lavoro
Un *gate* è un componente del flusso di lavoro che è possibile utilizzare per impedire che l'esecuzione di un flusso di lavoro proceda a meno che non vengano soddisfatte determinate condizioni. Un esempio di gate è **l'Approval** gate, in cui gli utenti devono inviare un'approvazione nella CodeCatalyst console prima che l'esecuzione del flusso di lavoro possa continuare.
È possibile aggiungere porte tra sequenze di azioni in un flusso di lavoro o prima della prima azione (che viene eseguita immediatamente dopo il download del **codice sorgente**). Puoi anche aggiungere porte dopo l'ultima azione, se necessario.
Per ulteriori informazioni sulle esecuzioni del flusso di lavoro, consulta[Esecuzione di un workflow](workflows-working-runs.md).
**Topics**
+ [Tipi di porte](#workflows-gates-types)
+ [Posso configurare un gate in modo che funzioni in parallelo a un'altra azione?](#workflows-approval-parallel)
+ [Posso usare un gate per impedire l'avvio di un workflow?](#workflows-gates-prevent)
+ [Limitazioni dei gate](#workflows-gate-limitations)
+ [Aggiungere un gate a un flusso di lavoro](workflows-gates-add.md)
+ [Sequenziamento di porte e azioni](workflows-gates-depends-on.md)
+ [Specificare la versione di un cancello](workflows-gates-version.md)
## Tipi di porte
Attualmente, Amazon CodeCatalyst supporta un tipo di cancello: il gate di **approvazione**. Per ulteriori informazioni, consulta [Richiesta di approvazioni per l'esecuzione del flusso di lavoro](workflows-approval.md).
## Posso configurare un gate in modo che funzioni in parallelo a un'altra azione?
No. Gates può funzionare solo prima o dopo un'azione. Per ulteriori informazioni, consulta [Sequenziamento di porte e azioni](workflows-gates-depends-on.md).
## Posso usare un gate per impedire l'avvio di un workflow?
Sì, con qualifiche.
È possibile impedire l'*esecuzione di attività* a un flusso di lavoro, il che è leggermente diverso dall'impedirne l'*avvio*.
Per impedire a un flusso di lavoro di eseguire attività, aggiungi un gate prima della prima azione in un flusso di lavoro. In questo scenario, *verrà avviata* l'esecuzione di un flusso di lavoro, vale a dire che scaricherà i file del repository di origine, ma gli verrà impedito di eseguire attività finché il gate non verrà sbloccato.
**Nota**
I flussi di lavoro che iniziano e poi vengono bloccati da un gate vengono comunque conteggiati nel *numero massimo di flussi di lavoro simultanei per quota di spazio* e altre quote. Per assicurarti di non superare le quote del flusso di lavoro, prendi in considerazione l'utilizzo di un trigger del flusso di lavoro per avviare un flusso di lavoro in modo condizionale anziché utilizzare un gate. Considerate anche l'utilizzo di una regola di approvazione delle pull request anziché di un gate. Per ulteriori informazioni su quote, trigger e regole di approvazione delle pull request, consulta [Quote per i flussi di lavoro in CodeCatalyst](workflows-quotas.md)[L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger](workflows-add-trigger.md), e. [Gestione dei requisiti per l'unione di una pull request con le regole di approvazione](source-pull-requests-approval-rules.md)
## Limitazioni dei gate
I gate presentano le seguenti limitazioni:
+ Gates non può essere utilizzato insieme alla funzionalità di condivisione del calcolo. Per ulteriori informazioni sull'utilizzo di questa caratteristica, consulta [Condivisione dell'elaborazione tra le azioni](compute-sharing.md).
+ I gate non possono essere utilizzati all'interno di gruppi di azione. Per ulteriori informazioni sui gruppi di azioni, vedere[Raggruppamento delle azioni in gruppi di azione](workflows-group-actions.md).
# Aggiungere un gate a un flusso di lavoro
In Amazon CodeCatalyst, puoi aggiungere un gate a un flusso di lavoro per impedirne lo svolgimento a meno che non vengano soddisfatte determinate condizioni. Utilizza le seguenti istruzioni per aggiungere un gate a un flusso di lavoro.
Per ulteriori informazioni sui gate, vedere[Garantire l'esecuzione di un flusso di lavoro](workflows-gates.md).
**Per aggiungere e configurare un cancello**
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. A sinistra, scegli **Gates**.
1. Nel catalogo dei gate, cerca un gate, quindi scegli il segno più (**\$1**) per aggiungerlo al tuo flusso di lavoro.
1. Configura il cancello. Scegli **Visual** per usare l'editor visuale o **YAML** per usare l'editor YAML. Per istruzioni dettagliate, vedi:
+ [Aggiungere un cancello di «Approvazione»](workflows-approval-add.md)
1. (Facoltativo) Scegli **Convalida** per assicurarti che il codice YAML sia valido.
1. Scegli **Conferma per confermare** le modifiche.
# Sequenziamento di porte e azioni
In Amazon CodeCatalyst, puoi configurare un gate da eseguire prima o dopo un'azione del flusso di lavoro, un gruppo di azioni o un gate. Ad esempio, potresti impostare un `Approval` gate da eseguire prima di un'`Deploy`azione. In questo caso, si dice che l'`Deploy`azione *dipenda dal* `Approval` cancello.
Per impostare le dipendenze tra le porte e le azioni, configura la proprietà **Depends on** del cancello o dell'azione. Per istruzioni, consulta [Impostazione delle dipendenze tra le azioni](workflows-depends-on-set-up.md). Le istruzioni a cui si fa riferimento si riferiscono alle *azioni* del flusso di lavoro ma si applicano anche ai gate.
Per un esempio di come configurare la proprietà **Depends on** con un gate, vedere[Esempio: un cancello di «approvazione»](workflows-approval-example.md).
Per ulteriori informazioni sui cancelli, vedere[Garantire l'esecuzione di un flusso di lavoro](workflows-gates.md).
Per ulteriori informazioni sulle azioni del flusso di lavoro, vedere[Configurazione delle azioni del flusso di lavoro](workflows-actions.md).
# Specificare la versione di un cancello
Per impostazione predefinita, quando aggiungi un gate a un workflow, CodeCatalyst aggiunge la versione completa al file di definizione del workflow utilizzando il formato:
`vmajor.minor.patch`
Per esempio:
```
My-Gate:
Identifier: aws/approval@v1
```
È possibile allungare la versione in modo che il flusso di lavoro utilizzi una versione principale o secondaria specifica del gate. Per istruzioni, consulta [Specificare la versione dell'azione da utilizzare](workflows-action-versions.md). L'argomento a cui si fa riferimento si riferisce alle azioni del flusso di lavoro ma si applica anche ai gate.
Per ulteriori informazioni sui gate in CodeCatalyst, vedere[Garantire l'esecuzione di un flusso di lavoro](workflows-gates.md).
# Richiesta di approvazioni per l'esecuzione del flusso di lavoro
È possibile configurare l'esecuzione di un flusso di lavoro in modo che richieda un'approvazione prima di procedere. A tale scopo, è necessario aggiungere una [porta](workflows-gates.md) di **approvazione** al flusso di lavoro. Un *cancello di approvazione* impedisce che un flusso di lavoro proceda finché un utente o un gruppo di utenti non invia una o più approvazioni nella console. CodeCatalyst Una volta concesse tutte le approvazioni, il gate viene «sbloccato» e l'esecuzione del flusso di lavoro può riprendere.
Utilizza un **Approval** gate nel tuo flusso di lavoro per dare ai team di sviluppo, operativi e di leadership la possibilità di esaminare le modifiche prima che vengano distribuite a un pubblico più ampio.
Per ulteriori informazioni sulle esecuzioni del flusso di lavoro, consulta[Esecuzione di un workflow](workflows-working-runs.md).
**Topics**
+ [Come posso sbloccare un cancello di approvazione?](#workflows-approval-conditions)
+ [Quando utilizzare la porta «Approvazione»](#workflows-approval-when)
+ [Chi può fornire un'approvazione?](#workflows-approval-who)
+ [Come faccio a notificare agli utenti che è necessaria un'approvazione?](#workflows-approval-notify-methods)
+ [Posso utilizzare una porta di «Approvazione» per impedire l'avvio di un flusso di lavoro?](#workflows-approval-prevent)
+ [Come funzionano le approvazioni dei flussi di lavoro con le modalità di esecuzione in coda, sostituita e parallela?](#workflows-approval-run-mode)
+ [Esempio: un cancello di «approvazione»](workflows-approval-example.md)
+ [Aggiungere un cancello di «Approvazione»](workflows-approval-add.md)
+ [Configurazione delle notifiche di approvazione](workflows-approval-notify.md)
+ [Approvazione o rifiuto dell'esecuzione di un flusso di lavoro](workflows-approval-approve.md)
+ [Porta «Approvazione» YAML](approval-ref.md)
## Come posso sbloccare un cancello di approvazione?
Per sbloccare un cancello di **approvazione**, devono essere soddisfatte *tutte* le seguenti condizioni:
+ **Condizione 1**: è necessario presentare il numero richiesto di approvazioni. Il numero richiesto di approvazioni è configurabile e ogni utente può inviare una singola approvazione.
+ **Condizione 2**: Tutte le approvazioni devono essere presentate prima del timeout del gate. Il cancello scade 14 giorni dopo l'attivazione. Questo periodo non è configurabile.
+ **Condizione 3**: nessuno deve rifiutare l'esecuzione del flusso di lavoro. Un singolo rifiuto causerà l'interruzione dell'esecuzione del flusso di lavoro.
+ **Condizione 4**: (Si applica solo se si utilizza la modalità di esecuzione sostituita). L'esecuzione non deve essere sostituita da un'esecuzione successiva. Per ulteriori informazioni, consulta [Come funzionano le approvazioni dei flussi di lavoro con le modalità di esecuzione in coda, sostituita e parallela?](#workflows-approval-run-mode).
**Se una qualsiasi delle condizioni non viene soddisfatta, CodeCatalyst interrompe il flusso di lavoro e imposta lo stato di esecuzione su **Non riuscito** (nel caso delle **condizioni da 1** a **3**) o **Sostituito** (nel caso della Condizione 4).**
## Quando utilizzare la porta «Approvazione»
In genere, si utilizza un gate di **approvazione** in un flusso di lavoro che distribuisce applicazioni e altre risorse su un server di produzione o in qualsiasi ambiente in cui è necessario convalidare gli standard di qualità. Posizionando il gate prima dell'implementazione in produzione, offri ai revisori la possibilità di convalidare la nuova revisione del software prima che diventi disponibile al pubblico.
## Chi può fornire un'approvazione?
Qualsiasi utente membro del progetto e con il ruolo di **collaboratore o** **amministratore del progetto** può fornire un'approvazione. Anche gli utenti con il ruolo di **amministratore dello spazio** che appartengono allo spazio del progetto possono fornire un'approvazione.
**Nota**
Gli utenti con il ruolo **Revisore** non possono fornire approvazioni.
## Come faccio a notificare agli utenti che è necessaria un'approvazione?
Per notificare agli utenti che è necessaria un'approvazione, devi:
+ Ho CodeCatalyst inviato loro una notifica Slack. Per ulteriori informazioni, consulta [Configurazione delle notifiche di approvazione](workflows-approval-notify.md).
+ Vai alla pagina della CodeCatalyst console in cui si trovano i pulsanti **Approva e** **Rifiuta** e incolla l'URL della pagina in un'applicazione di posta elettronica o di messaggistica indirizzata agli approvatori. Per ulteriori informazioni su come accedere a questa pagina, consulta. [Approvazione o rifiuto dell'esecuzione di un flusso di lavoro](workflows-approval-approve.md)
## Posso utilizzare una porta di «Approvazione» per impedire l'avvio di un flusso di lavoro?
Sì, con qualifiche. Per ulteriori informazioni, consulta [Posso usare un gate per impedire l'avvio di un workflow?](workflows-gates.md#workflows-gates-prevent).
## Come funzionano le approvazioni dei flussi di lavoro con le modalità di esecuzione in coda, sostituita e parallela?
[Quando si utilizza la modalità in coda, sostituita o di esecuzione parallela, la porta **Approval** funziona in modo simile alle azioni.](workflows-actions.md) Ti consigliamo di leggere le [Informazioni sulla modalità di esecuzione parallela](workflows-configure-runs.md#workflows-configure-runs-parallel) sezioni[Informazioni sulla modalità di esecuzione in coda](workflows-configure-runs.md#workflows-configure-runs-queued),[Informazioni sulla modalità di esecuzione sostituita](workflows-configure-runs.md#workflows-configure-runs-superseded), per acquisire familiarità con queste modalità di esecuzione. Una volta acquisita una conoscenza di base delle stesse, torna a questa sezione per scoprire come funzionano queste modalità di esecuzione quando è presente l'**Approval** gate.
Quando è presente l'**Approval** gate, le esecuzioni vengono elaborate come segue:
+ Se utilizzi la [modalità di esecuzione in coda](workflows-configure-runs.md#workflows-configure-runs-queued), le esecuzioni verranno messe in coda dopo l'esecuzione attualmente in attesa di approvazione al gate. Quando il gate viene sbloccato (ossia, tutte le approvazioni sono state concesse), la corsa successiva della coda avanza fino al gate e attende le approvazioni. Questo processo continua con l'elaborazione delle esecuzioni in coda attraverso il gate. one-by-one [Figure 1](#figure-1-workflow-queued-run-mode-ma)illustra questo processo.
+ Se si utilizza la modalità di [esecuzione sostituita, il comportamento è lo stesso della modalità](workflows-configure-runs.md#workflows-configure-runs-superseded) di esecuzione in coda, tranne per il fatto che invece di avere delle esecuzioni accumulate nella coda all'ingresso, le esecuzioni più recenti sostituiscono (sostituiscono) le esecuzioni precedenti. Non ci sono code e qualsiasi esecuzione attualmente in attesa di approvazione all'uscita verrà annullata e sostituita da una nuova esecuzione. [Figure 2](#figure-2-workflow-superseded-run-mode-ma)illustra questo processo.
+ Se utilizzi la [modalità di esecuzione parallela](workflows-configure-runs.md#workflows-configure-runs-parallel), le esecuzioni iniziano in parallelo e non si formano code. Ogni esecuzione viene elaborata immediatamente dal gate poiché non ci sono esecuzioni precedenti. [Figure 3](#figure-3-workflow-parallel-run-mode-ma)illustra questo processo.
**Figura 1****: «modalità di esecuzione in coda» e un cancello di approvazione**
![\[Come funziona una porta «Approvazione» con la «modalità di esecuzione in coda»\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/flows/runmode-queued-ma.png)
**Figura 2****: «Modalità di esecuzione sostituita» e porta di approvazione**
![\[Come funziona un gate «Approval» con la «modalità di esecuzione sostituita»\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/flows/runmode-superseded-ma.png)
**Figura 3****: «modalità di esecuzione parallela» e porta di approvazione**
![\[Come funziona un gate «Approval» con la «modalità di esecuzione parallela»\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/flows/runmode-parallel-ma.png)
# Esempio: un cancello di «approvazione»
L'esempio seguente mostra come aggiungere un gate di **approvazione** chiamato `Approval_01` tra due azioni chiamate`Staging`, e`Production`. L'`Staging`azione viene eseguita per prima, il `Approval_01` gate dopo e l'`Production`azione per ultima. L'`Production`azione viene eseguita solo se il `Approval_01` cancello è sbloccato. La `DependsOn` proprietà garantisce che le `Production` fasi `Staging``Approval_01`, e vengano eseguite in ordine sequenziale.
Per ulteriori informazioni sull'**Approval** gate, vedere[Richiesta di approvazioni per l'esecuzione del flusso di lavoro](workflows-approval.md).
```
Actions:
Staging: # Deploy to a staging server
Identifier: aws/ecs-deploy@v1
Configuration:
...
Approval_01:
Identifier: aws/approval@v1
DependsOn:
- Staging
Configuration:
ApprovalsRequired: 2
Production: # Deploy to a production server
Identifier: aws/ecs-deploy@v1
DependsOn:
- Approval_01
Configuration:
...
```
# Aggiungere un cancello di «Approvazione»
Per configurare il flusso di lavoro in modo che richieda un'approvazione, è necessario aggiungere la porta di **approvazione** al flusso di lavoro. Utilizza le seguenti istruzioni per aggiungere una porta di **approvazione** al tuo flusso di lavoro.
Per ulteriori informazioni su questo cancello, vedi[Richiesta di approvazioni per l'esecuzione del flusso di lavoro](workflows-approval.md).
------
#### [ Visual ]
**Per aggiungere una porta di «Approvazione» a un flusso di lavoro (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. **In alto a sinistra, scegli Gates.**
1. Nel catalogo **Gates**, in **Approvazione**, scegli il segno più (**\$1**).
1. Scegliete **Input** e, nel campo **Dipende da**, effettuate le seguenti operazioni.
Specificate un'azione, un gruppo di azioni o un gate che deve essere eseguito correttamente affinché questo gate possa funzionare. Per impostazione predefinita, quando aggiungi un gate a un workflow, il gate è impostato in modo da dipendere dall'ultima azione del workflow. Se rimuovi questa proprietà, il gate non dipenderà da nulla e verrà eseguito per primo, prima di altre azioni.
**Nota**
Un gate deve essere configurato per essere eseguito prima o dopo un'azione, un gruppo di azioni o un gate. Non può essere configurato per funzionare in parallelo con altre azioni, gruppi di azioni e gate.
Per ulteriori informazioni sulla funzionalità **Depends on**, vedere[Sequenziamento di porte e azioni](workflows-gates-depends-on.md).
1. Scegli la scheda **Configurazione**.
1. Nel campo **Gate name**, effettuate le seguenti operazioni.
Specificate il nome che volete dare al cancello. Tutti i nomi delle porte devono essere univoci all'interno del flusso di lavoro. I nomi delle porte sono limitati a caratteri alfanumerici (a-z, A-Z, 0-9), trattini (-) e caratteri di sottolineatura (\$1). Gli spazi non sono consentiti. Non è possibile utilizzare le virgolette per abilitare caratteri e spazi speciali nei nomi delle porte.
1. (Facoltativo) Nel campo **Numero di approvazioni**, procedi come segue.
Specificate il numero minimo di approvazioni necessarie per sbloccare l'**Approval** gate. Il minimo è`1`. Il massimo è`2`. Se omesso, il valore predefinito è`1`.
**Nota**
Se desideri omettere la `ApprovalsRequired` proprietà, rimuovi la `Configuration` sezione del gate dal file di definizione del flusso di lavoro.
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 una porta di «Approvazione» a un flusso di lavoro (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 `Approval` sezione e le proprietà sottostanti usando l'esempio seguente come guida. Per ulteriori informazioni, consultare [Porta «Approvazione» YAML](approval-ref.md) nella [Definizione YAML del flusso di lavoro](workflow-reference.md).
```
Actions:
MyApproval_01:
Identifier: aws/approval@v1
DependsOn:
- PreviousAction
Configuration:
ApprovalsRequired: 2
```
Per un altro esempio, consulta [Esempio: un cancello di «approvazione»](workflows-approval-example.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.**
------
# Configurazione delle notifiche di approvazione
Puoi fare in modo che venga CodeCatalyst inviata una notifica a un canale Slack per informare gli utenti che l'esecuzione di un flusso di lavoro richiede un'approvazione. Gli utenti visualizzano la notifica e fanno clic sul link al suo interno. Il link li porta a una pagina di CodeCatalyst approvazione in cui possono approvare o rifiutare il flusso di lavoro.
Puoi anche configurare le notifiche per informare gli utenti che un flusso di lavoro è stato approvato, rifiutato o che la richiesta di approvazione è scaduta.
Usa le seguenti istruzioni per configurare le notifiche di Slack.
**Prima di iniziare**
Assicurati di aver aggiunto un cancello di **approvazione** al tuo flusso di lavoro. Per ulteriori informazioni, consulta [Aggiungere un cancello di «Approvazione»](workflows-approval-add.md).
**Per inviare notifiche di approvazione del flusso di lavoro a un canale Slack**
1. Configura CodeCatalyst con Slack. Per ulteriori informazioni, consulta [Guida introduttiva alle notifiche di Slack](getting-started-notifications.md).
1. Nel CodeCatalyst progetto che contiene il flusso di lavoro che richiede un'approvazione, abilita le notifiche, se non sono già abilitate. Per abilitare le notifiche:
1. Vai al tuo progetto e nel riquadro di navigazione, scegli **Impostazioni progetto**.
1. In alto, scegli **Notifiche**.
1. In **Eventi di notifica**, scegli **Modifica notifiche**.
1. Attiva **l'approvazione del flusso di lavoro in sospeso** e scegli un canale Slack a cui inviare la CodeCatalyst notifica.
1. (Facoltativo) Attiva notifiche aggiuntive per avvisare gli utenti delle approvazioni approvate, rifiutate e scadute. Puoi attivare l'approvazione dell'**esecuzione del flusso di lavoro, l'esecuzione del **flusso di lavoro rifiutata****, l'approvazione del **flusso di lavoro sostituita e l'approvazione del **flusso** di lavoro è scaduta**. Accanto a ciascuna notifica, scegli il canale Slack a cui inviare la CodeCatalyst notifica.
1. Seleziona **Salva**.
# Approvazione o rifiuto dell'esecuzione di un flusso di lavoro
Le esecuzioni del flusso di lavoro che includono la porta di **approvazione** dovranno essere approvate o rifiutate. Gli utenti possono fornire la propria approvazione o rifiuto a partire da:
+ la console CodeCatalyst
+ un link fornito da un membro del team
+ una notifica automatica su Slack
Dopo che un utente ha fornito l'approvazione o il rifiuto, questa decisione non può essere annullata.
**Nota**
Solo alcuni utenti possono approvare o rifiutare l'esecuzione di un flusso di lavoro. Per ulteriori informazioni, consulta [Chi può fornire un'approvazione?](workflows-approval.md#workflows-approval-who).
**Prima di iniziare**
Assicurati di aver aggiunto un cancello di **approvazione** al tuo flusso di lavoro. Per ulteriori informazioni, consulta [Aggiungere un cancello di «Approvazione»](workflows-approval-add.md).
**Per approvare o rifiutare un flusso di lavoro, esegui a partire dalla console. CodeCatalyst**
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. Nel diagramma del flusso di lavoro, scegli la casella che rappresenta la porta di **approvazione**.
Viene visualizzato un pannello laterale.
**Nota**
A questo punto, puoi inviare l'URL di questa pagina ad altri approvatori, se lo desideri.
1. **In **Revisione della decisione**, scegli **Approva o Rifiuta**.**
1. (Facoltativo) In **Commento: facoltativo**, inserisci un commento che indichi il motivo per cui hai approvato o rifiutato l'esecuzione del flusso di lavoro.
1. Seleziona **Invia**.
**Per approvare o rifiutare un flusso di lavoro, esegui a partire da un link fornito da un membro del team.**
1. Scegli il link che ti è stato inviato dal membro del team. (Puoi chiedere al membro del tuo team di leggere la procedura precedente per ottenere il link.)
1. Accedi a CodeCatalyst, se richiesto.
Verrai reindirizzato alla pagina di approvazione dell'esecuzione del flusso di lavoro.
1. **In **Decisione di revisione**, scegli **Approva o Rifiuta**.**
1. (Facoltativo) In **Commento: facoltativo**, inserisci un commento che indichi il motivo per cui hai approvato o rifiutato l'esecuzione del flusso di lavoro.
1. Seleziona **Invia**.
**Per approvare o rifiutare un flusso di lavoro, esegui a partire da una notifica automatica di Slack**
1. Assicurati che le notifiche Slack siano configurate. Per informazioni, consulta [Configurazione delle notifiche di approvazione](workflows-approval-notify.md).
1. In Slack, nel canale a cui è stata inviata la notifica di approvazione, scegli il link nella notifica di approvazione.
1. Accedi a CodeCatalyst, se richiesto.
Verrai reindirizzato alla pagina di esecuzione del flusso di lavoro.
1. Nel diagramma del flusso di lavoro, scegli la porta di approvazione.
1. **In **Decisione di revisione**, scegli **Approva o Rifiuta**.**
1. (Facoltativo) In **Commento: facoltativo**, inserisci un commento che indichi il motivo per cui hai approvato o rifiutato l'esecuzione del flusso di lavoro.
1. Seleziona **Invia**.
# Porta «Approvazione» YAML
**Di seguito è riportata la definizione YAML della porta di approvazione.** Per imparare a usare questo cancello, vedi. [Richiesta di approvazioni per l'esecuzione del flusso di lavoro](workflows-approval.md)
Questa definizione di azione esiste come sezione all'interno di un file di definizione del flusso di lavoro più ampio. Per ulteriori informazioni su questo file, consulta [Definizione YAML del flusso di lavoro](workflow-reference.md).
**Nota**
La maggior parte delle proprietà YAML che seguono hanno elementi dell'interfaccia utente corrispondenti nell'editor visivo. **Per cercare un elemento dell'interfaccia utente, usa Ctrl\$1F.** L'elemento verrà elencato con la proprietà YAML associata.
```
# The workflow definition starts here.
# See Proprietà di primo livello for details.
Name: MyWorkflow
SchemaVersion: 1.0
Actions:
# The 'Approval' gate definition starts here.
Approval:
Identifier: aws/approval@v1
DependsOn:
- another-action
Configuration:
ApprovalsRequired: number
```
## Approval
(Obbligatorio)
Specificate il nome che volete dare al cancello. Tutti i nomi delle porte devono essere univoci all'interno del flusso di lavoro. I nomi delle porte sono limitati a caratteri alfanumerici (a-z, A-Z, 0-9), trattini (-) e caratteri di sottolineatura (\$1). Gli spazi non sono consentiti. Non è possibile utilizzare le virgolette per abilitare caratteri e spazi speciali nei nomi delle porte.
Default: `Approval_nn`.
**Interfaccia utente corrispondente: scheda di configurazione/nome del gate**
## Identifier
(*Approval*/**Identifier**)
(Obbligatorio)
Identifica la porta. La porta di **approvazione** supporta la versione`1.0.0`. Non modificate questa proprietà a meno che non vogliate abbreviare la versione. Per ulteriori informazioni, consulta [Specificare la versione dell'azione da utilizzare](workflows-action-versions.md).
Default: `aws/approval@v1`.
**Interfaccia utente corrispondente: Workflow diagram/ Approval \$1nn/ aws/approval @v1 label**
## DependsOn
(*Approval*/**DependsOn**)
(Facoltativo)
Specificare un'azione, un gruppo di azioni o un gate che deve essere eseguito correttamente affinché questo gate possa funzionare. Per impostazione predefinita, quando aggiungi un gate a un workflow, il gate è impostato in modo da dipendere dall'ultima azione del workflow. Se rimuovi questa proprietà, il gate non dipenderà da nulla e verrà eseguito per primo, prima di altre azioni.
**Nota**
Un gate deve essere configurato per essere eseguito prima o dopo un'azione, un gruppo di azioni o un gate. Non può essere configurato per funzionare in parallelo con altre azioni, gruppi di azioni e gate.
Per ulteriori informazioni sulla funzionalità **Depends on**, vedere[Sequenziamento di porte e azioni](workflows-gates-depends-on.md).
**Interfaccia utente corrispondente: scheda Inputs/ Depends on**
## Configuration
(*Approval*/**Configuration**)
(Facoltativo)
Una sezione in cui è possibile definire le proprietà di configurazione del gate.
Interfaccia utente corrispondente: scheda **Configurazione**
## ApprovalsRequired
(*Approval*/Configuration/**ApprovalsRequired**)
(Facoltativo)
Specificate il numero minimo di approvazioni necessarie per sbloccare la porta di **approvazione**. Il minimo è`1`. Il massimo è`2`. Se omesso, il valore predefinito è`1`.
**Nota**
Se desideri omettere la `ApprovalsRequired` proprietà, rimuovi la `Configuration` sezione del gate dal file di definizione del flusso di lavoro.
Interfaccia utente corrispondente: scheda di configurazione/ **Numero di approvazioni**
# Configurazione del comportamento di accodamento delle esecuzioni
Per impostazione predefinita CodeCatalyst, in Amazon, quando si verificano più flussi di lavoro contemporaneamente, li mette in CodeCatalyst coda e li elabora uno per uno, nell'ordine in cui sono stati avviati. Puoi modificare questo comportamento predefinito specificando una modalità di *esecuzione*. Esistono alcune modalità di esecuzione:
+ (Impostazione predefinita) Modalità di esecuzione in coda: CodeCatalyst i processi vengono eseguiti uno per uno
+ Modalità di esecuzione sostituita: CodeCatalyst i processi vengono eseguiti uno per uno, con le esecuzioni più recenti che sostituiscono quelle precedenti
+ Modalità di esecuzione parallela: CodeCatalyst i processi vengono eseguiti in parallelo
Per ulteriori informazioni sulle esecuzioni del flusso di lavoro, vedere[Esecuzione di un workflow](workflows-working-runs.md).
**Topics**
+ [Informazioni sulla modalità di esecuzione in coda](#workflows-configure-runs-queued)
+ [Informazioni sulla modalità di esecuzione sostituita](#workflows-configure-runs-superseded)
+ [Informazioni sulla modalità di esecuzione parallela](#workflows-configure-runs-parallel)
+ [Configurazione della modalità di esecuzione](#workflows-configure-runs-configure)
## Informazioni sulla modalità di esecuzione in coda
In *modalità di esecuzione in coda, le esecuzioni vengono eseguite* in serie, con le esecuzioni in attesa che formano una coda.
Le code si formano nei punti di ingresso alle azioni e ai gruppi di azioni, quindi è possibile avere *più code all'interno dello stesso flusso di lavoro (vedi*). [Figure 1](#figure-1-workflow-queued-run-mode) Quando un'esecuzione in coda entra in un'azione, l'azione viene bloccata e non possono entrare altre esecuzioni. Quando la corsa termina ed esce dall'azione, l'azione viene sbloccata e pronta per l'esecuzione successiva.
[Figure 1](#figure-1-workflow-queued-run-mode)illustra un flusso di lavoro configurato in modalità di esecuzione in coda. Mostra le seguenti informazioni:
+ Sette esecuzioni si fanno strada nel flusso di lavoro.
+ Due code: una all'esterno dell'ingresso della sorgente di input (**Repo:main**) e una all'esterno dell'ingresso dell'azione. **BuildTestActionGroup**
+ Due blocchi bloccati: la sorgente di ingresso (**Repo:main**) e il. **BuildTestActionGroup**
Ecco come andranno le cose man mano che il flusso di lavoro viene eseguito e terminato l'elaborazione:
+ **Quando **run-4D444** termina la clonazione del repository di origine, uscirà dalla sorgente di input e si unirà alla coda dietro RUN-3c333.** **Quindi, RUN-5e555 entrerà nella sorgente di input.**
+ Quando **Run-1a111** terminerà la costruzione e il test, uscirà dall'azione ed entrerà nell'**BuildTestActionGroup**azione. **DeployAction** Quindi, **Run-2b222** entrerà in azione. **BuildTestActionGroup**
**Figura 1**: Un flusso di lavoro configurato in «modalità di esecuzione in coda»
![\[Un flusso di lavoro configurato in «modalità di esecuzione in coda»\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png)
Utilizza la modalità di esecuzione in coda se:
+ **Desideri mantenere una one-to-one relazione tra funzionalità ed esecuzioni: queste funzionalità possono essere raggruppate quando si utilizza la modalità sostituita**. Ad esempio, quando si unisce la funzionalità 1 nel commit 1, viene avviata l'esecuzione 1 e quando si unisce la funzionalità 2 nel commit 2, viene avviata l'esecuzione 2 e così via. Se dovessi utilizzare la modalità sostituita anziché la modalità in coda, le tue funzionalità (e i commit) verranno raggruppati nella sequenza che sostituisce le altre.
+ **Vuoi evitare condizioni di gara e problemi imprevisti che possono verificarsi quando si utilizza la modalità parallela**. Ad esempio, se due sviluppatori di software, Wang e Saanvi, avviano il flusso di lavoro all'incirca nello stesso momento per la distribuzione in un cluster Amazon ECS, l'esecuzione di Wang potrebbe avviare i test di integrazione sul cluster mentre l'esecuzione di Saanvi distribuisce un nuovo codice applicativo nel cluster, causando il fallimento dei test di Wang o il test del codice sbagliato. Come altro esempio, potresti avere un obiettivo che non dispone di un meccanismo di blocco, nel qual caso le due esecuzioni potrebbero sovrascrivere le reciproche modifiche in modi imprevisti.
+ **Vuoi limitare il carico** sulle risorse di calcolo CodeCatalyst utilizzate per elaborare le tue esecuzioni. Ad esempio, se hai tre azioni nel tuo flusso di lavoro, puoi avere un massimo di tre esecuzioni contemporaneamente. L'imposizione di un limite al numero di esecuzioni che possono essere eseguite contemporaneamente rende il throughput di esecuzione più prevedibile.
+ **Si desidera limitare il numero di richieste effettuate a servizi di terze parti dal flusso** di lavoro. Ad esempio, il flusso di lavoro potrebbe avere un'azione di compilazione che include istruzioni per estrarre un'immagine da Docker Hub. [Docker Hub limita il numero di pull request](https://www.docker.com/increase-rate-limits) che puoi effettuare a un determinato numero all'ora per account e, se superi il limite, non potrai più accedere. L'utilizzo della modalità di esecuzione in coda per rallentare il throughput di esecuzione avrà l'effetto di generare meno richieste all'ora verso Docker Hub, limitando così il potenziale di blocchi e i conseguenti errori di compilazione ed esecuzione.
Dimensione massima della **coda**: 50
Note sulla dimensione **massima della coda:**
+ La dimensione massima della coda si riferisce al numero massimo di esecuzioni consentite in *tutte le code* del flusso di lavoro.
+ Se una coda supera le 50 esecuzioni, CodeCatalyst interrompe la 51a esecuzione e le successive.
Comportamento di **errore**:
Se un'esecuzione non risponde mentre viene elaborata da un'azione, le esecuzioni successive vengono mantenute in coda fino al timeout dell'azione. Le azioni scadono dopo un'ora.
Se un'esecuzione fallisce all'interno di un'azione, la prima esecuzione in coda che l'ha preceduta può continuare.
## Informazioni sulla modalità di esecuzione sostituita
La modalità di *esecuzione sostituita è la stessa della modalità* di esecuzione in *coda*, tranne per il fatto che:
+ Se un'esecuzione in coda raggiunge un'altra esecuzione in coda, l'esecuzione successiva sostituisce (sostituisce) l'esecuzione precedente e l'esecuzione precedente viene annullata e contrassegnata come «sostituita».
+ Come risultato del comportamento descritto nel primo bullet, una coda può includere una sola esecuzione quando viene utilizzata la modalità di esecuzione sostituita.
Utilizzando il workflow in [Figure 1](#figure-1-workflow-queued-run-mode) come guida, l'applicazione della modalità di esecuzione sostituita a questo flusso di lavoro comporterebbe quanto segue:
+ **Run-7g777** **sostituirebbe le altre due esecuzioni nella sua coda e sarebbe l'unica esecuzione rimasta nella coda \$11.** **RUN-6f666 e **RUN-5e555 verrebbero annullati**.**
+ **Run-3c333** ****sostituirebbe RUN-2b222 e sarebbe l'unica esecuzione rimasta nella coda \$12.**** **Run-2b222** verrebbe annullata.
Usa la modalità di esecuzione sostituita se desideri:
+ velocità di trasmissione migliore rispetto alla modalità in coda
+ ancora meno richieste verso i servizi di terze parti rispetto alla modalità in coda; questo è vantaggioso se il servizio di terze parti ha limiti di tariffa, come Docker Hub
## Informazioni sulla modalità di esecuzione parallela
In *modalità di esecuzione parallela*, le esecuzioni sono indipendenti l'una dall'altra e non attendono il completamento delle altre esecuzioni prima di iniziare. Non ci sono code e la velocità di esecuzione è limitata solo dalla velocità di completamento delle azioni all'interno del flusso di lavoro.
Utilizza la modalità di esecuzione parallela in ambienti di sviluppo in cui ogni utente ha il proprio ramo di funzionalità e si distribuisce su destinazioni non condivise da altri utenti.
**Importante**
Se disponi di un target condiviso su cui più utenti possono eseguire l'implementazione, ad esempio una funzione Lambda in un ambiente di produzione, non utilizzare la modalità parallela, poiché potrebbero verificarsi condizioni di gara. Una *condizione di gara* si verifica quando l'esecuzione di un flusso di lavoro parallelo tenta di modificare contemporaneamente una risorsa condivisa, con risultati imprevedibili.
**Numero massimo di esecuzioni parallele**: 1000 per CodeCatalyst spazio
## Configurazione della modalità di esecuzione
È possibile impostare la modalità di esecuzione in coda, sostituita o in parallelo. L'impostazione predefinita è in coda.
Quando si modifica la modalità di esecuzione da coda o sostituita a parallela CodeCatalyst , annulla le esecuzioni in coda e consente alle esecuzioni attualmente elaborate da un'azione di terminare prima di annullarle.
Quando si modifica la modalità di esecuzione da parallela a quella in coda o sostituita, consente il completamento di CodeCatalyst tutte le esecuzioni parallele attualmente in esecuzione. Tutte le esecuzioni avviate dopo aver cambiato la modalità di esecuzione in coda o sostituita utilizzano la nuova modalità.
------
#### [ Visual ]
**Per modificare la modalità di esecuzione utilizzando l'editor visuale**
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. In alto a destra, scegli Proprietà del **flusso di lavoro**.
1. Espandi **Avanzate** e, in **modalità Esegui**, scegli una delle seguenti opzioni:
1. In **coda: vedi** [Informazioni sulla modalità di esecuzione in coda](#workflows-configure-runs-queued)
1. **Sostituito**: vedi [Informazioni sulla modalità di esecuzione sostituita](#workflows-configure-runs-superseded)
1. **Parallelo**: vedi [Informazioni sulla modalità di esecuzione parallela](#workflows-configure-runs-parallel)
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 cambiare la modalità di esecuzione utilizzando l'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 la `RunMode` proprietà, in questo modo:
```
Name: Workflow_6d39
SchemaVersion: "1.0"
RunMode: QUEUED|SUPERSEDED|PARALLEL
```
Per ulteriori informazioni, consulta la descrizione della `RunMode` proprietà nella [Proprietà di primo livello](workflow-reference.md#workflow.top.level) sezione del[Definizione YAML del flusso di lavoro](workflow-reference.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.**
------
# Memorizzazione nella cache dei file tra le esecuzioni del workflow
Quando la memorizzazione nella cache dei file è abilitata, le azioni di compilazione e test salvano i file su disco in una cache e li ripristinano da tale cache nelle successive esecuzioni del flusso di lavoro. La memorizzazione nella cache riduce la latenza causata dalla creazione o dal download di dipendenze che non sono cambiate tra un'esecuzione e l'altra. CodeCatalyst supporta anche le cache di fallback, che possono essere utilizzate per ripristinare cache parziali contenenti alcune delle dipendenze necessarie. Questo aiuta a ridurre l'impatto sulla latenza di una mancata memorizzazione della cache.
**Nota**
La memorizzazione nella cache dei file è disponibile solo con le azioni di CodeCatalyst [build](build-workflow-actions.md) e [test](test-workflow-actions.md) di Amazon e solo quando sono configurate per utilizzare il tipo di **EC2**[elaborazione](workflows-working-compute.md#compute.types).
**Topics**
+ [Informazioni sulla memorizzazione nella cache dei file](#workflows-caching.files)
+ [Creazione di una cache](#workflows-caching.fallback)
+ [Vincoli di memorizzazione nella cache dei file](#workflows-caching.constraints)
## Informazioni sulla memorizzazione nella cache dei file
La memorizzazione nella cache dei file consente di organizzare i dati in più cache, ognuna delle quali è referenziata nella proprietà. `FileCaching` Ogni cache salva una directory specificata da un determinato percorso. La directory specificata verrà ripristinata nelle future esecuzioni del flusso di lavoro. Di seguito è riportato un esempio di frammento YAML per la memorizzazione nella cache con più cache denominate and. `cacheKey1` `cacheKey2`
```
Actions:
BuildMyNpmApp:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: npm install
- Run: npm run test
Caching:
FileCaching:
cacheKey1:
Path: file1.txt
RestoreKeys:
- restoreKey1
cacheKey2:
Path: /root/repository
RestoreKeys:
- restoreKey2
- restoreKey3
```
**Nota**
CodeCatalyst utilizza la memorizzazione nella cache multilivello, che consiste in una cache locale e una cache remota. Quando le flotte di macchine o le macchine on-demand predisposte rilevano una perdita di cache in una cache locale, le dipendenze verranno ripristinate da una cache remota. Di conseguenza, alcune esecuzioni di azioni potrebbero presentare una latenza dovuta al download di una cache remota.
CodeCatalyst applica restrizioni di accesso alla cache per garantire che un'azione in un flusso di lavoro non possa modificare le cache di un flusso di lavoro diverso. Ciò protegge ogni flusso di lavoro da altri che potrebbero inviare dati errati con impatto sulle build o sulle implementazioni. Le restrizioni vengono applicate con cache-scopes che isolano le cache per ogni flusso di lavoro e associazione di filiali. Ad esempio, `workflow-A` in branch `feature-A` ha una cache di file diversa rispetto a quella del ramo gemello. `workflow-A` `feature-B`
Gli errori di cache si verificano quando un flusso di lavoro cerca una cache di file specificata e non riesce a trovarla. Ciò può verificarsi per diversi motivi, ad esempio quando viene creato un nuovo ramo o quando si fa riferimento a una nuova cache che non è ancora stata creata. Può verificarsi anche alla scadenza di una cache, che per impostazione predefinita si verifica 14 giorni dopo l'ultimo utilizzo. Per mitigare gli errori nella cache e aumentare la frequenza degli accessi alla cache, CodeCatalyst supporta le cache di fallback. Le cache di fallback sono cache alternative e offrono l'opportunità di ripristinare cache parziali, che possono essere una versione precedente di una cache. Una cache viene ripristinata cercando innanzitutto una corrispondenza nel nome della proprietà e, se non viene trovata, valuta. `FileCaching` `RestoreKeys` Se si verifica un errore nella cache sia per il nome della proprietà che per tutto`RestoreKeys`, il flusso di lavoro continuerà a funzionare, poiché la memorizzazione nella cache è la soluzione migliore e non è garantita.
## Creazione di una cache
Puoi usare le seguenti istruzioni per aggiungere una cache al tuo flusso di lavoro.
------
#### [ Visual ]
**Per aggiungere una cache utilizzando l'editor visuale**
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 l'azione in cui desideri aggiungere la cache.
1. Scegliere **Configuration (Configurazione)**.
1. In **Memorizzazione nella cache dei file - opzionale**, scegli **Aggiungi cache** e inserisci le informazioni nei campi, come segue:
**Chiave**
Specificate il nome della proprietà della cache principale. I nomi delle proprietà della cache devono essere univoci all'interno del flusso di lavoro. Ogni azione può contenere fino a cinque immissioni`FileCaching`.
**Path**
Specificate il percorso associato per la cache.
**Chiavi di ripristino: opzionale**
Specificare la chiave di ripristino da utilizzare come fallback quando non è possibile trovare la proprietà della cache principale. I nomi delle chiavi di ripristino devono essere univoci all'interno del flusso di lavoro. Ogni cache può contenere fino a cinque voci`RestoreKeys`.
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, quindi scegliete nuovamente Commit.**
------
#### [ YAML ]
**Per aggiungere una cache utilizzando l'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. In un'azione del flusso di lavoro, aggiungi un codice simile al seguente:
```
action-name:
Configuration:
Steps: ...
Caching:
FileCaching:
key-name:
Path: file-path
# # Specify any additional fallback caches
# RestoreKeys:
# - restore-key
```
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.**
------
## Vincoli di memorizzazione nella cache dei file
Di seguito sono riportati i vincoli per il nome della proprietà e: `RestoreKeys`
+ I nomi devono essere univoci all'interno di un flusso di lavoro.
+ I nomi sono limitati a caratteri alfanumerici (A-Z, a-z, 0-9), trattini (-) e caratteri di sottolineatura (\$1).
+ I nomi possono contenere fino a 180 caratteri.
+ Ogni azione può contenere fino a cinque cache. `FileCaching`
+ Ogni cache può contenere fino a cinque voci. `RestoreKeys`
Di seguito sono riportati i vincoli per i percorsi:
+ Gli asterischi (\$1) non sono consentiti.
+ I percorsi possono contenere fino a 255 caratteri.
# Visualizzazione dello stato e dei dettagli dell'esecuzione del flusso di lavoro
IN Amazon CodeCatalyst, puoi visualizzare lo stato e i dettagli di un singolo flusso di lavoro eseguito o di più esecuzioni contemporaneamente.
Per un elenco dei possibili stati di esecuzione, consulta[Stati di esecuzione del flusso di lavoro](workflows-view-run-status.md).
**Nota**
È inoltre possibile visualizzare lo stato del flusso di lavoro, che è diverso dallo stato di *esecuzione* del flusso di lavoro. Per ulteriori informazioni, consulta [Visualizzazione dello stato di un flusso di lavoro](workflows-view-status.md).
Per ulteriori informazioni sulle esecuzioni del flusso di lavoro, vedere[Esecuzione di un workflow](workflows-working-runs.md).
**Topics**
+ [Visualizzazione dello stato e dei dettagli di una singola esecuzione](#workflows-view-run-single)
+ [Visualizzazione dello stato e dei dettagli di tutte le esecuzioni del progetto](#workflows-view-run-all)
+ [Visualizzazione dello stato e dei dettagli di tutte le esecuzioni di uno specifico workflow](#workflows-view-run-wf)
+ [Visualizzazione delle esecuzioni di un flusso di lavoro nel diagramma del flusso di lavoro](#workflows-view-run-wf-diagram)
## Visualizzazione dello stato e dei dettagli di una singola esecuzione
Potresti voler visualizzare lo stato e i dettagli di un singolo flusso di lavoro eseguito per verificare se ha avuto esito positivo, per vedere a che ora è stato completato o per vedere chi o cosa l'ha avviato.
**Per visualizzare lo stato e i dettagli di una singola esecuzione**
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. Sotto il nome del flusso di lavoro, scegli **Esegue**.
1. Nella **cronologia di esecuzione**, nella colonna **Run ID**, scegli una corsa. Ad esempio, `Run-95a4d`.
1. Sotto il nome della corsa, esegui una delle seguenti operazioni:
+ **Visuale** per visualizzare un diagramma del flusso di lavoro che mostra le azioni eseguite dal flusso di lavoro e il relativo stato (vedi[Stati di esecuzione del flusso di lavoro](workflows-view-run-status.md)). Questa vista mostra anche il repository e il ramo di origine utilizzati durante l'esecuzione.
Nel diagramma del flusso di lavoro, scegli un'azione per visualizzare dettagli come log, report e output generati dall'azione durante l'esecuzione. Le informazioni mostrate dipendono dal tipo di azione selezionato. Per ulteriori informazioni sulla visualizzazione dei log di compilazione o distribuzione, consulta [Visualizzazione dei risultati di un'azione di compilazione](build-view-results.md) o. [Visualizzazione dei log di distribuzione](deploy-deployment-logs.md)
+ **YAML** per visualizzare il file di definizione del flusso di lavoro utilizzato per l'esecuzione.
+ **Artefatti per visualizzare gli artefatti** prodotti dal flusso di lavoro in esecuzione. Per ulteriori informazioni sugli artefatti, vedi [Condivisione di artefatti e file tra azioni](workflows-working-artifacts.md).
+ **Rapporti** per visualizzare i rapporti sui test e altri tipi di report prodotti dal flusso di lavoro eseguiti. Per ulteriori informazioni sui report, vedere[Tipi di report sulla qualità](test-workflow-actions.md#test-reporting).
+ **Variabili** per visualizzare le variabili di output prodotte dall'esecuzione del flusso di lavoro. Per ulteriori informazioni sulle variabili, vedere[Utilizzo delle variabili nei flussi di lavoro](workflows-working-with-variables.md).
**Nota**
Se il flusso di lavoro principale dell'esecuzione è stato eliminato, nella parte superiore della pagina dei dettagli dell'esecuzione viene visualizzato un messaggio che indica questo fatto.
## Visualizzazione dello stato e dei dettagli di tutte le esecuzioni del progetto
Potresti voler visualizzare lo stato e i dettagli di tutti i flussi di lavoro eseguiti all'interno del tuo progetto, capire quanta attività di flusso di lavoro è in corso nel tuo progetto e conoscere lo stato generale dei tuoi flussi di lavoro.
**Per visualizzare lo stato e i dettagli di tutte le esecuzioni del progetto**
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. **In **Flussi di lavoro**, scegli Esecuzioni.**
Vengono visualizzate tutte le esecuzioni, per tutti i flussi di lavoro, in tutte le filiali, in tutti i repository del progetto.
La pagina include le seguenti colonne:
+ **Run ID**: l'identificatore univoco della corsa. Scegli il link Run ID per visualizzare informazioni dettagliate sulla corsa.
+ **Stato: lo** stato di elaborazione del workflow in esecuzione. Per ulteriori informazioni sugli stati di esecuzione, vedere[Stati di esecuzione del flusso di lavoro](workflows-view-run-status.md).
+ **Trigger**: la persona, il commit, la pull request (PR) o la pianificazione che ha avviato l'esecuzione del flusso di lavoro. Per ulteriori informazioni, consulta [L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger](workflows-add-trigger.md).
+ Flusso di **lavoro**: il nome del flusso di lavoro per il quale è stata avviata un'esecuzione e l'archivio di origine e il ramo in cui risiede il file di definizione del flusso di lavoro. Potrebbe essere necessario espandere la larghezza della colonna per visualizzare queste informazioni.
**Nota**
Se questa colonna è impostata **su Non disponibile**, in genere è perché il flusso di lavoro associato è stato eliminato o spostato.
+ **Ora di inizio**: l'ora in cui è iniziata l'esecuzione del flusso di lavoro.
+ **Durata**: il tempo impiegato per l'elaborazione dell'esecuzione del flusso di lavoro. Durate molto lunghe o molto brevi potrebbero indicare problemi.
+ Ora di **fine: l'ora** in cui è terminata l'esecuzione del flusso di lavoro.
## Visualizzazione dello stato e dei dettagli di tutte le esecuzioni di uno specifico workflow
Potresti voler visualizzare lo stato e i dettagli di tutte le esecuzioni associate a un flusso di lavoro specifico per vedere se alcune esecuzioni stanno creando colli di bottiglia all'interno del flusso di lavoro o per vedere quali esecuzioni sono attualmente in corso o sono state completate.
**Per visualizzare lo stato e i dettagli di tutte le esecuzioni di uno specifico workflow**
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. Sotto il nome del flusso di lavoro, scegli **Esegue**.
Vengono visualizzate le esecuzioni associate al flusso di lavoro scelto.
La pagina è divisa in due sezioni:
+ **Esecuzioni attive**: visualizza le esecuzioni in corso. Queste esecuzioni si svolgeranno in uno dei seguenti stati: **In corso**.
+ **Cronologia delle esecuzioni**: visualizza le esecuzioni completate (ovvero non in corso).
Per ulteriori informazioni sugli stati di esecuzione, vedere[Stati di esecuzione del flusso di lavoro](workflows-view-run-status.md).
## Visualizzazione delle esecuzioni di un flusso di lavoro nel diagramma del flusso di lavoro
È possibile visualizzare lo stato di tutte le esecuzioni di un flusso di lavoro man mano che procedono insieme nel flusso di lavoro. Le esecuzioni vengono visualizzate all'interno del diagramma del flusso di lavoro (anziché in una visualizzazione a elenco). Ciò offre una rappresentazione visiva di quali esecuzioni vengono elaborate, con quali azioni e quali esecuzioni sono in attesa in coda.
**Per visualizzare lo stato di più esecuzioni man mano che procedono insieme all'interno di un flusso di lavoro**
**Nota**
Questa procedura si applica solo se il flusso di lavoro utilizza la modalità di esecuzione in coda o sostituita. Per ulteriori informazioni, consulta [Configurazione del comportamento di accodamento delle esecuzioni](workflows-configure-runs.md).
1. [Apri la console all'indirizzo https://codecatalyst.aws/ CodeCatalyst .](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.
**Nota**
Assicurati di visualizzare una pagina del flusso di lavoro e non una pagina di esecuzione.
1. Scegli la scheda **Stato più recente** in alto a sinistra.
Viene visualizzato un diagramma del flusso di lavoro.
1. Esamina il diagramma del flusso di lavoro. Il diagramma mostra tutte le esecuzioni attualmente in corso all'interno del flusso di lavoro e le ultime esecuzioni terminate. Più specificamente:
+ Le esecuzioni che appaiono in alto, prima di **Sources**, sono in coda e attendono di iniziare.
+ Le esecuzioni che compaiono tra le azioni vengono messe in coda e attendono di essere elaborate dall'azione successiva.
+ Le esecuzioni che compaiono all'interno di un'azione sono 1. attualmente in fase di elaborazione da parte dell'azione, 2. hanno terminato l'elaborazione da parte dell'azione o 3. non sono state elaborate dall'azione (in genere perché un'azione precedente non è riuscita).