

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

# Configurazione delle azioni del flusso di lavoro
<a name="workflows-actions"></a>

Un'*azione* è l'elemento costitutivo principale di un flusso di lavoro e definisce un'unità logica di lavoro, o attività, da eseguire durante l'esecuzione di un flusso di lavoro. In genere, un flusso di lavoro include più azioni eseguite in sequenza o in parallelo a seconda di come le hai configurate.

**Topics**
+ [Tipi di operazione](#workflows-actions-types)
+ [Aggiungere un'azione a un flusso di lavoro](workflows-add-action.md)
+ [Rimuovere un'azione da un flusso di lavoro](workflows-delete-action.md)
+ [Sviluppo di un'azione personalizzata](workflows-custom-action.md)
+ [Raggruppamento delle azioni in gruppi di azione](workflows-group-actions.md)
+ [Azioni di sequenziamento](workflows-depends-on.md)
+ [Condivisione di artefatti e file tra azioni](workflows-working-artifacts.md)
+ [Specificare la versione dell'azione da utilizzare](workflows-action-versions.md)
+ [Elenco delle versioni action disponibili](workflows-action-versions-determine.md)
+ [Visualizzazione del codice sorgente di un'azione](workflows-view-source.md)
+ [Integrazione con GitHub Actions](integrations-github-actions.md)

## Tipi di operazione
<a name="workflows-actions-types"></a>

All'interno di un CodeCatalyst flusso di lavoro Amazon, puoi utilizzare i seguenti tipi di azioni.

**Topics**
+ [CodeCatalyst azioni](#workflows-actions-types-cc)
+ [CodeCatalyst Azioni di laboratorio](#workflows-actions-types-cc-labs)
+ [GitHub Azioni](#workflows-actions-types-github)
+ [Operazioni di terze parti](#workflows-actions-types-3p)

### CodeCatalyst azioni
<a name="workflows-actions-types-cc"></a>

Un'*CodeCatalyst azione* è un'azione creata, gestita e completamente supportata dal team di CodeCatalyst sviluppo.

Esistono CodeCatalyst azioni per la creazione, il test e la distribuzione di applicazioni, nonché per l'esecuzione di varie attività, come l'invocazione di una funzione. AWS Lambda 

Sono disponibili le seguenti CodeCatalyst azioni:
+ **Compila**

  Questa azione crea i tuoi artefatti ed esegue i tuoi unit test in un contenitore Docker. Per ulteriori informazioni, consulta [Aggiungere l'azione di compilazione](build-add-action.md).
+ **Test**

  Questa azione esegue test di integrazione e di sistema rispetto all'applicazione o agli artefatti. Per ulteriori informazioni, consulta [Aggiungere l'azione di test](test-add-action.md).
+ **Pubblicazione su Amazon S3**

  Questa azione copia gli artefatti dell'applicazione in un bucket Amazon S3. Per ulteriori informazioni, consulta [Pubblicazione di file su Amazon S3 con un flusso di lavoro](s3-pub-action.md).
+ **AWS CDK bootstrap**

  Questa azione fornisce le risorse necessarie per distribuire l' AWS CDK app CDK. Per ulteriori informazioni, consulta [Avvio di un' AWS CDK app con un flusso di lavoro](cdk-boot-action.md).
+ **AWS CDK distribuire**

  Questa azione sintetizza e distribuisce un'app. AWS Cloud Development Kit (AWS CDK) Per ulteriori informazioni, consulta [Implementazione di un' AWS CDK app con un flusso di lavoro](cdk-dep-action.md).
+ **AWS Lambda invocare**

  Questa azione richiama una funzione. AWS Lambda Per ulteriori informazioni, consulta [Richiamo di una funzione Lambda utilizzando un flusso di lavoro](lam-invoke-action.md).
+ **GitHub Azioni**

  Questa azione consente di *CodeCatalyst*eseguire GitHub azioni all'interno di un CodeCatalyst flusso di lavoro. Per ulteriori informazioni, consulta [Richiamo di una funzione Lambda utilizzando un flusso di lavoro](lam-invoke-action.md).
+ **Distribuisci lo stack CloudFormation **

  Questa azione distribuisce CloudFormation gli stack. Per ulteriori informazioni, consulta [Implementazione di uno stack CloudFormation](deploy-action-cfn.md).
+ **Esegui la distribuzione su Amazon ECS**

  Questa azione registra una definizione di attività Amazon ECS e la distribuisce su un servizio Amazon ECS. Per ulteriori informazioni, consulta [Distribuzione su Amazon ECS con un flusso di lavoro](deploy-action-ecs.md).
+ **Esegui la distribuzione nel cluster Kubernetes**

  Questa azione distribuisce un'applicazione in un cluster Kubernetes. Per ulteriori informazioni, consulta [Implementazione su Amazon EKS con un flusso di lavoro](deploy-action-eks.md).
+ **Renderizza la definizione delle attività di Amazon ECS**

  Questa azione inserisce un URI dell'immagine del contenitore in un file JSON di definizione delle attività di Amazon ECS, creando un nuovo file di definizione delle attività. Per ulteriori informazioni, consulta [Modifica della definizione di un'attività Amazon ECS](render-ecs-action.md).

La documentazione relativa CodeCatalyst alle azioni è disponibile in questa guida e nel file readme di ogni azione.

Per informazioni sulle CodeCatalyst azioni disponibili e su come aggiungerne una a un flusso di lavoro, consulta[Aggiungere un'azione a un flusso di lavoro](workflows-add-action.md).

### CodeCatalyst Azioni di laboratorio
<a name="workflows-actions-types-cc-labs"></a>

Un'*azione CodeCatalyst Labs* è un'azione che fa parte di Amazon CodeCatalyst Labs, un banco di prova per applicazioni sperimentali. CodeCatalyst Le azioni di laboratorio sono state sviluppate per mostrare le integrazioni con i servizi. AWS 

Sono disponibili le seguenti azioni CodeCatalyst Labs:
+ **Distribuisci su Hosting AWS Amplify **

  Questa azione distribuisce un'applicazione su Amplify Hosting.
+ **Distribuisci su AWS App Runner**

  Questa azione distribuisce l'immagine più recente in un archivio di immagini di origine su App Runner.
+ **Esegui la distribuzione su Amazon CloudFront e Amazon S3**

  Questa azione distribuisce un'applicazione su Amazon S3. CloudFront 
+ **Esegui la distribuzione con AWS SAM**

  Questa azione distribuisce la tua applicazione serverless con AWS Serverless Application Model ().AWS SAM
+ **Invalidare Amazon Cache CloudFront **

  Questa azione invalida una CloudFront cache per un determinato set di percorsi.
+ **Webhook in uscita**

  Questa azione consente agli utenti di inviare messaggi all'interno di un flusso di lavoro a un server Web arbitrario utilizzando una richiesta HTTPS.
+ **Pubblica su AWS CodeArtifact**

  Questa azione pubblica i pacchetti in un CodeArtifact repository.
+ **Pubblica su Amazon SNS**

  Questa azione consente agli utenti di integrarsi con Amazon SNS creando un argomento, pubblicandolo su un argomento o iscrivendosi a un argomento.
+ **Esegui il push su Amazon ECR**

  Questa azione crea e pubblica un'immagine Docker in un repository Amazon Elastic Container Registry (Amazon ECR).
+ **Scansione con Amazon CodeGuru Security**

  Questa azione crea un archivio zip di un percorso di codice configurato e utilizza CodeGuru Security per eseguire una scansione del codice.
+ **Terraform Community Edition**

  Questa azione esegue Terraform Community Edition `plan` e `apply` le operazioni.

La documentazione per le azioni CodeCatalyst di Labs è disponibile nel readme di ogni azione.

Per informazioni sull'aggiunta di un'azione CodeCatalyst Labs a un flusso di lavoro e sulla visualizzazione del relativo readme, consulta. [Aggiungere un'azione a un flusso di lavoro](workflows-add-action.md)

### GitHub Azioni
<a name="workflows-actions-types-github"></a>

Un'*GitHub azione* è molto simile a un'[CodeCatalyst azione](#workflows-actions-types-cc), tranne per il fatto che è stata sviluppata per essere utilizzata con i GitHub flussi di lavoro. Per informazioni dettagliate sulle GitHub azioni, consulta la documentazione relativa [GitHub alle azioni](https://docs.github.com/en/actions).

È possibile utilizzare GitHub le azioni insieme alle CodeCatalyst azioni native in un CodeCatalyst flusso di lavoro.

Per comodità, la CodeCatalyst console fornisce l'accesso a diverse GitHub azioni popolari. Puoi anche utilizzare qualsiasi GitHub azione elencata nel [GitHub Marketplace](https://github.com/marketplace/actions) (soggetta ad alcune limitazioni).

La documentazione relativa GitHub alle azioni è disponibile nel file readme di ogni azione.

Per ulteriori informazioni, consulta [Integrazione con GitHub Actions](integrations-github-actions.md).

### Operazioni di terze parti
<a name="workflows-actions-types-3p"></a>

Un'*azione di terze parti* è un'azione creata da un fornitore terzo e resa disponibile nella CodeCatalyst console. Esempi di azioni di terze parti includono le azioni **Mend SCA** e **SonarCloud Scan**, create rispettivamente da Mend e Sonar.

La documentazione per le azioni di terze parti è disponibile nel file readme di ogni azione. Documentazione aggiuntiva potrebbe essere fornita anche dal fornitore terzo.

Per informazioni sull'aggiunta di un'azione di terze parti a un flusso di lavoro e sulla visualizzazione del relativo file readme, consulta. [Aggiungere un'azione a un flusso di lavoro](workflows-add-action.md)

# Aggiungere un'azione a un flusso di lavoro
<a name="workflows-add-action"></a>

Utilizza le seguenti istruzioni per aggiungere un'azione a un flusso di lavoro e quindi configurarla.

**Per aggiungere e configurare un'azione**

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 **\$1 Azioni**, viene visualizzato il catalogo **Azioni**.

1. Nell'elenco a discesa, esegui una delle seguenti operazioni:
   + Scegli **Amazon CodeCatalyst** per visualizzare azioni [CodeCatalyst](workflows-actions.md#workflows-actions-types-cc), [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) o [di terze parti](workflows-actions.md#workflows-actions-types-3p).
     + CodeCatalyst le azioni hanno un' AWS etichetta **per**.
     + CodeCatalyst Le azioni Labs hanno l'** CodeCatalyst etichetta by Labs.**
     + Le azioni di terze parti hanno un'*vendor*etichetta **per**, dove *vendor* è il nome del fornitore terzo.
   + Scegli **GitHub**di visualizzare un [elenco curato di GitHub ](integrations-github-action-add-curated.md) azioni.

1. Nel catalogo delle azioni, cerca un'azione, quindi esegui una delle seguenti operazioni:
   + Scegli il segno più (**\$1**) per aggiungere l'azione al tuo flusso di lavoro.
   + Scegli il nome dell'azione per visualizzarne il file readme.

1. Configura l'azione. Scegli **Visual** per usare l'editor visuale o **YAML** per usare l'editor YAML. Per istruzioni dettagliate, consulta i seguenti collegamenti.

   Per istruzioni sull'aggiunta di [CodeCatalystazioni](workflows-actions.md#workflows-actions-types-cc), consulta:
   + [Aggiungere l'azione di compilazione](build-add-action.md)
   + [Aggiungere l'azione di test](test-add-action.md)
   + [Aggiungere l'azione «Deploy to Amazon ECS»](deploy-action-ecs-adding.md)
   + [Aggiungere l'azione «Deploy to Kubernetes cluster»](deploy-action-eks-adding.md)
   + [Aggiungere l'azione «Deploy stack» CloudFormation](deploy-action-cfn-adding.md)
   + [Aggiungere l'azione 'AWS CDK deploy'](cdk-dep-action-add.md)
   + [Aggiungere l'azione 'AWS CDK bootstrap'](cdk-boot-action-add.md)
   + [Aggiungere l'azione «Amazon S3 publish»](s3-pub-action-add.md)
   + [Aggiungere l'AWS Lambda azione «invoca»](lam-invoke-action-add.md)
   + [Aggiungere l'azione «Render Amazon ECS task definition»](render-ecs-action-add.md)

   Per istruzioni sull'aggiunta di [azioni CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs), consulta:
   + Il file readme è l'azione. Puoi trovare il file readme scegliendo il nome dell'azione nel catalogo delle azioni.

   Per istruzioni sull'aggiunta di [GitHub azioni](workflows-actions.md#workflows-actions-types-github), consulta:
   + [Integrazione con GitHub Actions](integrations-github-actions.md)

   Per istruzioni sull'aggiunta [di azioni di terze parti](workflows-actions.md#workflows-actions-types-3p), consulta:
   + Il file readme è l'azione. Puoi trovare il file readme scegliendo il nome dell'azione nel catalogo delle azioni.

1. (Facoltativo) Scegli **Convalida** per assicurarti che il codice YAML sia valido.

1. Scegli **Conferma per confermare** le modifiche.

# Rimuovere un'azione da un flusso di lavoro
<a name="workflows-delete-action"></a>

Utilizza le seguenti istruzioni per rimuovere un'azione da un flusso di lavoro.

------
#### [ Visual ]

**Per rimuovere un'azione 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, nell'azione da rimuovere, scegliete l'icona con i puntini di sospensione verticali () ![\[Ellipsis.\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/images/flows/elipsis.png) e scegliete Rimuovi.**

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 rimuovere un'azione 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. Trova la sezione di YAML che contiene l'azione che desideri rimuovere.

   Seleziona la sezione e premi il tasto Elimina sulla tastiera.

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.**

------

# Sviluppo di un'azione personalizzata
<a name="workflows-custom-action"></a>

Puoi sviluppare un'azione personalizzata da utilizzare nei tuoi flussi di lavoro utilizzando l' CodeCatalyst Action Development Kit (ADK). Puoi quindi pubblicare l'azione nel catalogo delle CodeCatalyst azioni, in modo che altri CodeCatalyst utenti possano visualizzarla e utilizzarla nei propri flussi di lavoro.

**Per sviluppare, testare e pubblicare un'azione (attività di alto livello)**

1. Installa gli strumenti e i pacchetti necessari per sviluppare un'azione.

1. Crea un CodeCatalyst repository per archiviare il codice d'azione.

1. Inizializza l'azione. Questo stabilisce i file sorgente richiesti dall'azione, incluso un file di definizione dell'azione (`action.yml`) che puoi aggiornare con il tuo codice.

1. Avvia il codice d'azione per ottenere gli strumenti e le librerie necessari per creare, testare e rilasciare il progetto d'azione.

1. Crea l'azione sul tuo computer locale e invia le modifiche al tuo CodeCatalyst repository.

1. Testa l'azione con i test unitari a livello locale ed esegui il flusso di lavoro generato da ADK in. CodeCatalyst

1. Pubblica l'azione nel catalogo CodeCatalyst delle azioni scegliendo il pulsante **Pubblica** nella CodeCatalyst console.

Per i passaggi dettagliati, consulta la [Amazon CodeCatalyst Action Development Kit Development Kit Development Guide](https://docs.aws.amazon.com/codecatalyst/latest/adk/what-is-action-development-kit.html).

# Raggruppamento delle azioni in gruppi di azione
<a name="workflows-group-actions"></a>

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

**Nota**  
Non è possibile annidare i gruppi di azioni all'interno di altri gruppi di azioni o azioni.

**Topics**
+ [Definizione di un gruppo di azioni](#workflows-define-action-group)
+ [Esempio: definizione di due gruppi di azioni](workflows-group-actions-example.md)

## Definizione di un gruppo di azioni
<a name="workflows-define-action-group"></a>

Utilizzate le seguenti istruzioni per definire un gruppo di CodeCatalyst azioni.

------
#### [ Visual ]

*Non disponibile. Scegli YAML per visualizzare le istruzioni YAML.*

------
#### [ YAML ]

**Per definire un gruppo**

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.

1. Scegli **Modifica**.

1. Scegli **YAML**.

1. In`Actions`, aggiungi un codice simile al seguente:

   ```
   Actions:
     action-group-name: 
       Actions:
         action-1:
           Identifier: aws/build@v1
           Configuration:
             ...
         action-2:
           Identifier: aws/build@v1
           Configuration:
             ...
   ```

   Per un altro esempio, consulta [Esempio: definizione di due gruppi di azioni](workflows-group-actions-example.md). Per ulteriori informazioni, vedere la descrizione [Azioni](workflow-reference.md#actions-reference) della `action-group-name` proprietà nel[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.**

------

# Esempio: definizione di due gruppi di azioni
<a name="workflows-group-actions-example"></a>

L'esempio seguente mostra come definire due gruppi di CodeCatalyst azioni Amazon: `BuildAndTest` e`Deploy`. Il `BuildAndTest` gruppo include due azioni (`Build`e`Test`) e il `Deploy` gruppo include anche due azioni (`DeployCloudFormationStack`e`DeployToECS`).

```
Actions:
  BuildAndTest: # Action group 1
    Actions:
      Build:
        Identifier: aws/build@v1
        Configuration:
          ...
      Test:
        Identifier: aws/managed-test@v1
        Configuration:
  Deploy: #Action group 2
    Actions:
      DeployCloudFormationStack:
        Identifier: aws/cfn-deploy@v1
        Configuration:
          ...
      DeployToECS:
        Identifier: aws/ecs-deploy@v1
        Configuration:
          ...
```

# Azioni di sequenziamento
<a name="workflows-depends-on"></a>

Per impostazione predefinita, quando aggiungi azioni a un flusso di lavoro, queste vengono aggiunte fianco a fianco nell'[editor visivo](workflow.md#workflow.editors). Ciò significa che le azioni verranno eseguite in parallelo quando si avvia l'esecuzione di un flusso di lavoro. Se desideri che le azioni vengano eseguite in ordine sequenziale (e appaiano verticalmente nell'editor visivo), devi impostare le dipendenze tra di esse. Ad esempio, è possibile impostare un'`Test`azione in modo che dipenda dall'azione in modo che l'`Build`azione di test venga eseguita dopo l'azione di creazione.

È possibile impostare dipendenze tra azioni e gruppi di azioni. Puoi anche configurare one-to-many le dipendenze in modo che un'azione dipenda da diverse altre per iniziare. Consulta le linee guida riportate in [Impostazione delle dipendenze tra le azioni](workflows-depends-on-set-up.md) per assicurarti che la configurazione delle dipendenze sia conforme alla sintassi YAML del flusso di lavoro.

**Topics**
+ [Esempi di come configurare le dipendenze tra le azioni](workflows-depends-on-examples.md)
+ [Impostazione delle dipendenze tra le azioni](workflows-depends-on-set-up.md)

# Esempi di come configurare le dipendenze tra le azioni
<a name="workflows-depends-on-examples"></a>

Gli esempi seguenti mostrano come configurare le dipendenze tra azioni e gruppi nel file di definizione del flusso di lavoro.

**Topics**
+ [Esempio: configurazione di una dipendenza semplice](#workflows-depends-on-example-simple)
+ [Esempio: configurazione di un gruppo di azioni in modo che dipenda da un'azione](#workflows-depends-on-example-action-groups-actions)
+ [Esempio: configurazione di un gruppo di azioni in modo che dipenda da un altro gruppo di azioni](#workflows-depends-on-example-two-action-groups)
+ [Esempio: configurazione di un gruppo di azioni in modo che dipenda da più azioni](#workflows-depends-on-example-advanced)

## Esempio: configurazione di una dipendenza semplice
<a name="workflows-depends-on-example-simple"></a>

L'esempio seguente mostra come configurare un'`Test`azione in modo che dipenda dall'`Build`azione che utilizza la `DependsOn` proprietà.

```
Actions:
  Build:
    Identifier: aws/build@v1
    Configuration:
      ...
  Test:
    DependsOn:
      - Build
    Identifier: aws/managed-test@v1
     Configuration:
       ...
```

## Esempio: configurazione di un gruppo di azioni in modo che dipenda da un'azione
<a name="workflows-depends-on-example-action-groups-actions"></a>

L'esempio seguente mostra come configurare un gruppo di `DeployGroup` azioni in modo che dipenda dall'`FirstAction`azione. Notate che l'azione e il gruppo di azioni sono allo stesso livello.

```
Actions:
  FirstAction: #An action outside an action group
    Identifier: aws/github-actions-runner@v1
    Configuration:
      ...
  DeployGroup: #An action group containing two actions
    DependsOn: 
      - FirstAction
    Actions:
      DeployAction1:
      ...
      DeployAction2:
      ...
```

## Esempio: configurazione di un gruppo di azioni in modo che dipenda da un altro gruppo di azioni
<a name="workflows-depends-on-example-two-action-groups"></a>

L'esempio seguente mostra come configurare un gruppo di `DeployGroup` azioni in modo che dipenda dal gruppo di `BuildAndTestGroup` azioni. Notate che i gruppi di azione si trovano allo stesso livello.

```
Actions:
  BuildAndTestGroup: # Action group 1
    Actions:
      BuildAction:
      ...
      TestAction:
      ...
  DeployGroup: #Action group 2
    DependsOn: 
      - BuildAndTestGroup
    Actions:
      DeployAction1:
      ...
      DeployAction2:
      ...
```

## Esempio: configurazione di un gruppo di azioni in modo che dipenda da più azioni
<a name="workflows-depends-on-example-advanced"></a>

L'esempio seguente mostra come configurare un gruppo di `DeployGroup` azioni in modo che dipenda dall'`FirstAction`azione, dall'`SecondAction`azione e dal gruppo di `BuildAndTestGroup` azioni. Notate che `DeployGroup` è allo stesso livello di `FirstAction``SecondAction`, e`BuildAndTestGroup`.

```
Actions:
  FirstAction: #An action outside an action group
    ...
  SecondAction: #Another action 
    ...
  BuildAndTestGroup: #Action group 1
    Actions:
      Build:
      ...
      Test:
      ...
  DeployGroup: #Action group 2
    DependsOn: 
      - FirstAction
      - SecondAction
      - BuildAndTestGroup
    Actions:
      DeployAction1:
      ...
      DeployAction2:
      ...
```

# Impostazione delle dipendenze tra le azioni
<a name="workflows-depends-on-set-up"></a>

Utilizza le seguenti istruzioni per impostare le dipendenze tra le azioni in un flusso di lavoro.

Quando configuri le dipendenze, segui queste linee guida:
+ Se un'azione è all'interno di un gruppo, tale azione può dipendere solo da altre azioni all'interno dello stesso gruppo.
+ Le azioni e i gruppi di azioni possono dipendere da altre azioni e gruppi di azioni *allo stesso livello* nella gerarchia YAML, ma *non* a un livello diverso.

------
#### [ Visual ]

**Per impostare le dipendenze 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 che dipenderà da un'altra azione.

1. Scegli la scheda **Input**.

1. In **Depends on - opzionale**, procedi come segue:

   Specificate un'azione, un gruppo di azioni o un gate che deve essere eseguito correttamente affinché questa azione venga eseguita.

   Per ulteriori informazioni sulla funzionalità «dipende da», vedere. [Azioni di sequenziamento](workflows-depends-on.md)

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 impostare le dipendenze 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 che dipenderà da un'altra, aggiungi un codice simile al seguente:

   ```
   action-name:
     DependsOn:
       - action-1
   ```

   Per ulteriori esempi, consulta [Esempi di come configurare le dipendenze tra le azioni](workflows-depends-on-examples.md). Per linee guida generali, vedi[Impostazione delle dipendenze tra le azioni](#workflows-depends-on-set-up). Per ulteriori informazioni, consulta la descrizione della `DependsOn` proprietà nella sezione [Definizione YAML del flusso di lavoro](workflow-reference.md) Per le tue azioni.

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.**

------

# Condivisione di artefatti e file tra azioni
<a name="workflows-working-artifacts"></a>

Un *artefatto* è l'output di un'azione del flusso di lavoro e in genere è costituito da una cartella o da un archivio di file. Gli artefatti sono importanti perché consentono di condividere file e informazioni tra le azioni.

*Ad esempio, potresti avere un'azione di compilazione che *genera* un `sam-template.yml` file, ma desideri un'azione di distribuzione per utilizzarla.* In questo scenario, si utilizzerebbe un artefatto per consentire all'azione di compilazione di condividere il `sam-template.yml` file con l'azione di distribuzione. Il codice potrebbe essere simile al seguente:

```
Actions:
  BuildAction:
    Identifier: aws/build@v1
    Steps:
      - Run: sam package --output-template-file sam-template.yml
    Outputs:
      Artifacts:
        - Name: MYARTIFACT
          Files:
            - sam-template.yml
  DeployAction:
    Identifier: aws/cfn-deploy@v1  
    Inputs:
      Artifacts:
        - MYARTIFACT
    Configuration:
      template: sam-template.yml
```

Nel codice precedente, l'azione build (`BuildAction`) genera un `sam-template.yml` file e quindi lo aggiunge a un artefatto di output chiamato. `MYARTIFACT` Una successiva deploy action (`DeployAction`) specifica `MYARTIFACT` come input l'accesso al file. `sam-template.yml`

**Topics**
+ [Posso condividere gli artefatti senza specificarli come output e input?](#workflows-working-artifacts-share)
+ [Posso condividere artefatti tra flussi di lavoro?](#workflows-working-artifacts-share-wf)
+ [Esempi di manufatti](workflows-working-artifacts-ex.md)
+ [Definizione di un artefatto di output](workflows-working-artifacts-output.md)
+ [Definizione di un artefatto di input](workflows-working-artifacts-refer.md)
+ [Riferimento ai file in un artefatto](workflows-working-artifacts-refer-files.md)
+ [Scaricamento di artefatti](workflows-download-workflow-outputs.md)

## Posso condividere gli artefatti senza specificarli come output e input?
<a name="workflows-working-artifacts-share"></a>

Sì, puoi condividere artefatti tra azioni senza specificarli nelle sezioni e del codice YAML delle tue azioni. `Outputs` `Inputs` Per fare ciò, devi attivare la condivisione del calcolo. Per ulteriori informazioni sulla condivisione del calcolo e su come specificare gli artefatti quando è attivata, consulta. [Condivisione dell'elaborazione tra le azioni](compute-sharing.md) 

**Nota**  
Sebbene la funzionalità di condivisione del calcolo consenta di semplificare il codice YAML del flusso di lavoro eliminando la necessità delle `Inputs` sezioni `Outputs` e, è necessario conoscere alcune limitazioni prima di attivarla. Per informazioni su queste limitazioni, consulta. [Considerazioni sulla condivisione del calcolo](compute-sharing.md#compare-compute-sharing)

## Posso condividere artefatti tra flussi di lavoro?
<a name="workflows-working-artifacts-share-wf"></a>

No, non puoi condividere artefatti tra flussi di lavoro diversi; tuttavia, puoi condividere artefatti tra azioni all'interno dello stesso flusso di lavoro.

# Esempi di manufatti
<a name="workflows-working-artifacts-ex"></a>

I seguenti esempi mostrano come generare, inserire e fare riferimento agli artefatti nel file di definizione del CodeCatalyst flusso di lavoro di Amazon.

**Topics**
+ [Esempio: output di un artefatto](#workflows-working-artifacts-ex-basic)
+ [Esempio: inserimento di un artefatto generato da un'altra azione](#workflows-working-artifacts-ex-ref)
+ [Esempio: riferimento a file in più artefatti](#workflows-working-artifacts-ex-ref-file)
+ [Esempio: fare riferimento a un file in un singolo artefatto](#workflows-working-artifacts-ex-ref-file-one)
+ [Esempio: fare riferimento a un file in un artefatto quando è presente un WorkflowSource](#workflows-working-artifacts-ex-ref-file-wf-source)
+ [Esempio: fare riferimento a un file in un artefatto quando è presente un gruppo di azioni](#workflows-working-artifacts-ex-groups)

## Esempio: output di un artefatto
<a name="workflows-working-artifacts-ex-basic"></a>

L'esempio seguente mostra come generare un artefatto che include due file.jar.

```
Actions:
  Build:
    Identifier: aws/build@v1
    Outputs:
      Artifacts:
        - Name: ARTIFACT1
          Files:
            - build-output/file1.jar
            - build-output/file2.jar
```

## Esempio: inserimento di un artefatto generato da un'altra azione
<a name="workflows-working-artifacts-ex-ref"></a>

L'esempio seguente mostra come generare un artefatto chiamato e `ARTIFACT4` inserirlo in`BuildActionA`. `BuildActionB`

```
Actions:
  BuildActionA:
    Identifier: aws/build@v1  
    Outputs:
      Artifacts:
        - Name: ARTIFACT4
          Files:
            - build-output/file1.jar
            - build-output/file2.jar
  BuildActionB:
    Identifier: aws/build@v1  
    Inputs:
      Artifacts:
        - ARTIFACT4
    Configuration:
```

## Esempio: riferimento a file in più artefatti
<a name="workflows-working-artifacts-ex-ref-file"></a>

L'esempio seguente mostra come generare due artefatti denominati `ART5` e `ART6` in `BuildActionC` e quindi fare riferimento a due file denominati `file5.txt` (in artifact`ART5`) e (in artifact) in `file6.txt` (under). `ART6` `BuildActionD` `Steps`

**Nota**  
Per ulteriori informazioni sulla referenziazione dei file, vedere. [Riferimento ai file in un artefatto](workflows-working-artifacts-refer-files.md)

**Nota**  
Sebbene l'esempio mostri il `$CATALYST_SOURCE_DIR_ART5` prefisso utilizzato, è possibile ometterlo. Questo perché `ART5` è l'input *principale*. Per ulteriori informazioni sull'input principale, consulta[Riferimento ai file in un artefatto](workflows-working-artifacts-refer-files.md). 

```
Actions:
  BuildActionC:
    Identifier: aws/build@v1  
    Outputs:
      Artifacts:
        - Name: ART5
          Files:
            - build-output/file5.txt
        - Name: ART6
          Files:
            - build-output/file6.txt
  BuildActionD:
    Identifier: aws/build@v1  
    Inputs:
      Artifacts:
        - ART5
        - ART6
    Configuration:
      Steps:
        - run: cd $CATALYST_SOURCE_DIR_ART5/build-output && cat file5.txt
        - run: cd $CATALYST_SOURCE_DIR_ART6/build-output && cat file6.txt
```

## Esempio: fare riferimento a un file in un singolo artefatto
<a name="workflows-working-artifacts-ex-ref-file-one"></a>

L'esempio seguente mostra come generare un elemento denominato `ART7` in e quindi fare riferimento `file7.txt` (nell'`BuildActionE`artefatto`ART7`) in (sotto). `BuildActionF` `Steps`

Notate come il riferimento non richieda il `$CATALYST_SOURCE_DIR_` *artifact-name* prefisso davanti alla `build-output` directory come accadeva in. [Esempio: riferimento a file in più artefatti](#workflows-working-artifacts-ex-ref-file) Questo perché c'è solo un elemento specificato in`Inputs`.

**Nota**  
Per ulteriori informazioni sui file di riferimento, vedere[Riferimento ai file in un artefatto](workflows-working-artifacts-refer-files.md).

```
Actions:
  BuildActionE:
    Identifier: aws/build@v1  
    Outputs:
      Artifacts:
        - Name: ART7
          Files:
            - build-output/file7.txt
  BuildActionF:
    Identifier: aws/build@v1  
    Inputs:
      Artifacts:
        - ART7
    Configuration:
      Steps:
        - run: cd build-output && cat file7.txt
```

## Esempio: fare riferimento a un file in un artefatto quando è presente un WorkflowSource
<a name="workflows-working-artifacts-ex-ref-file-wf-source"></a>

L'esempio seguente mostra come generare un elemento denominato `ART8` in e quindi fare riferimento `file8.txt` (nell'`BuildActionG`artefatto`ART8`) in (sotto). `BuildActionH` `Steps`

Notate come il riferimento richieda il `$CATALYST_SOURCE_DIR_` *artifact-name* prefisso, come accadeva in. [Esempio: riferimento a file in più artefatti](#workflows-working-artifacts-ex-ref-file) Questo perché ci sono più elementi specificati in `Inputs` (una fonte e un artefatto), quindi è necessario il prefisso per indicare dove cercare il file.

**Nota**  
Per ulteriori informazioni sulla referenziazione dei file, vedere. [Riferimento ai file in un artefatto](workflows-working-artifacts-refer-files.md)

```
Actions:
  BuildActionG:
    Identifier: aws/build@v1  
    Outputs:
      Artifacts:
        - Name: ART8
          Files:
            - build-output/file8.txt
  BuildActionH:
    Identifier: aws/build@v1  
    Inputs:
      Sources:
        - WorkflowSource
      Artifacts:
        - ART8
    Configuration:
      Steps:
        - run: cd $CATALYST_SOURCE_DIR_ART8/build-output && cat file8.txt
```

## Esempio: fare riferimento a un file in un artefatto quando è presente un gruppo di azioni
<a name="workflows-working-artifacts-ex-groups"></a>

L'esempio seguente mostra come generare un artefatto denominato `ART9` in e quindi fare riferimento `file9.txt` (in `ActionGroup1` un artefatto) in. `ActionI` `ART9` `ActionJ`

Per ulteriori informazioni sulla referenziazione dei file, vedere. [Riferimento ai file in un artefatto](workflows-working-artifacts-refer-files.md)

```
Actions:
  ActionGroup1:
    Actions:
      ActionI:
        Identifier: aws/build@v1
        Outputs:
          Artifacts:
            - Name: ART9
              Files:
                - build-output/file9.yml
      ActionJ:
        Identifier: aws/cfn-deploy@v1 
        Inputs:
          Sources:
            - WorkflowSource
          Artifacts:
            - ART9
        Configuration:
          template: /artifacts/ActionGroup1@ActionJ/ART9/build-output/file9.yml
```

# Definizione di un artefatto di output
<a name="workflows-working-artifacts-output"></a>

Utilizza le seguenti istruzioni per definire un artefatto che desideri venga generato da CodeCatalyst un'azione Amazon. Questo artefatto diventa quindi disponibile per altre azioni da utilizzare.

**Nota**  
Non tutte le azioni supportano gli artefatti di output. **Per determinare se la tua azione li supporta, segui le istruzioni dell'editor visivo che seguono e verifica se l'azione include un pulsante relativo agli **artefatti di output** nella scheda Output.** Se sì, gli artefatti di output sono supportati. 

------
#### [ Visual ]

**Per definire un artefatto di output 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 che produrrà l'artefatto.

1. Seleziona la scheda **Outputs (Output)**.

1. **In **Artefatti, scegli Aggiungi artefatto**.**

1. Scegli **Aggiungi artefatto** e inserisci le informazioni nei campi, come segue.

    **Crea il nome dell'artefatto** 

   Specificate il nome di un artefatto generato dall'azione. I nomi degli Artifact devono essere univoci all'interno di un flusso di lavoro e sono limitati a caratteri alfanumerici (a-z, A-Z, 0-9) e caratteri di sottolineatura (\$1). Spazi, trattini (-) e altri caratteri speciali non sono consentiti. Non è possibile utilizzare le virgolette per abilitare spazi, trattini e altri caratteri speciali nei nomi degli artefatti di output.

   Per ulteriori informazioni sugli artefatti, inclusi esempi, vedere. [Condivisione di artefatti e file tra azioni](workflows-working-artifacts.md)

    **File prodotti da build** 

   Specificate i file CodeCatalyst inclusi nell'artefatto generato dall'azione. Questi file vengono generati dall'azione del flusso di lavoro durante l'esecuzione e sono disponibili anche nell'archivio di origine. I percorsi dei file possono risiedere in un repository di origine o in un elemento di un'azione precedente e sono relativi al repository di origine o alla radice dell'elemento. È possibile utilizzare modelli a globo per specificare i percorsi. Esempi:
   + Per specificare un singolo file che si trova nella radice della posizione di creazione o della posizione del repository di origine, usa. `my-file.jar`
   + Per specificare un singolo file in una sottodirectory, usa `directory/my-file.jar` o. `directory/subdirectory/my-file.jar`
   + Per specificare tutti i file, utilizzare`"**/*"`. Il pattern a `**` glob indica che deve corrispondere a un numero qualsiasi di sottodirectory.
   + Per specificare tutti i file e le directory in una directory denominata, usa. `directory` `"directory/**/*"` Il pattern a `**` glob indica che deve corrispondere a un numero qualsiasi di sottodirectory.
   + Per specificare tutti i file in una directory denominata`directory`, ma non nessuna delle sue sottodirectory, usa. `"directory/*"` 
**Nota**  
Se il percorso del file include uno o più asterischi (`*`) o un altro carattere speciale, racchiudi il percorso tra virgolette doppie (). `""` Per ulteriori informazioni sui caratteri speciali, vedere. [Linee guida e convenzioni sulla sintassi](workflow-reference.md#workflow.terms.syntax.conv)

   Per ulteriori informazioni sugli artefatti, inclusi esempi, vedere. [Condivisione di artefatti e file tra azioni](workflows-working-artifacts.md)
**Nota**  
Potrebbe essere necessario aggiungere un prefisso al percorso del file per indicare in quale elemento o fonte trovarlo. Per ulteriori informazioni, consultare [Riferimento ai file del repository di origine](workflows-sources-reference-files.md) e [Riferimento ai file in un artefatto](workflows-working-artifacts-refer-files.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 definire un artefatto di output utilizzando l'editor YAML**

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.

1. Scegli **Modifica**.

1. Scegli **YAML**.

1. In un'azione del flusso di lavoro, aggiungi un codice simile al seguente:

   ```
   action-name:
     Outputs:
       Artifacts:
         - Name: artifact-name
           Files:
             - file-path-1
             - file-path-2
   ```

   Per ulteriori esempi, consulta [Esempi di manufatti](workflows-working-artifacts-ex.md). Per ulteriori informazioni, consulta la sezione [Definizione YAML del flusso di lavoro](workflow-reference.md) dedicata alla tua azione.

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.**

------

# Definizione di un artefatto di input
<a name="workflows-working-artifacts-refer"></a>

Se desideri utilizzare un artefatto generato da un'altra CodeCatalyst azione Amazon, devi specificarlo come input per l'azione corrente. Potresti essere in grado di specificare più artefatti come input, dipende dall'azione. Per ulteriori informazioni, consulta la sezione dedicata all'azione. [Definizione YAML del flusso di lavoro](workflow-reference.md)

**Nota**  
Non è possibile fare riferimento agli artefatti di altri flussi di lavoro.

Utilizzate le seguenti istruzioni per specificare un artefatto di un'altra azione come input per l'azione corrente.

**Prerequisito**  
Prima di iniziare, assicuratevi di aver generato l'artefatto dall'altra azione. Per ulteriori informazioni, consulta [Definizione di un artefatto di output](workflows-working-artifacts-output.md). L'emissione dell'artefatto lo rende disponibile per altre azioni da utilizzare.

------
#### [ Visual ]

**Specificare un artefatto come input per un'azione (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, scegliete l'azione in cui desiderate specificare un artefatto come input.

1. **Scegliete Ingressi.**

1. In **Artifacts, facoltativo, procedi** come segue:

   Specificate gli artefatti delle azioni precedenti che desiderate fornire come input per questa azione. Questi artefatti devono essere già definiti come artefatti di output nelle azioni precedenti.

   Se non si specifica alcun artefatto di input, è necessario specificare almeno un repository di origine in. `action-name/Inputs/Sources`

   Per ulteriori informazioni sugli artefatti, inclusi esempi, vedere. [Condivisione di artefatti e file tra azioni](workflows-working-artifacts.md)
**Nota**  
Se l'elenco a discesa **Artifacts - opzionale** non è disponibile (editor visivo) o se si verificano errori durante la convalida di YAML (editor YAML), è possibile che l'azione supporti un solo input. In questo caso, prova a rimuovere l'input sorgente.

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 specificare un artefatto come input per un'azione (editor YAML)**

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.

1. Scegli **Modifica**.

1. Scegli **YAML**.

1. Nell'azione in cui desiderate specificare l'artefatto come input, aggiungete un codice simile al seguente:

   ```
   action-name:
     Inputs:
       Artifacts:
         - artifact-name
   ```

   Per ulteriori esempi, consulta [Esempi di manufatti](workflows-working-artifacts-ex.md).

1. (Facoltativo) Scegliete **Convalida per convalidare** il codice YAML del flusso di lavoro prima del commit.

1. **Scegliete **Commit**, inserite un messaggio di commit e scegliete nuovamente Commit.**

------

# Riferimento ai file in un artefatto
<a name="workflows-working-artifacts-refer-files"></a>

Se hai un file che si trova all'interno di un artefatto e devi fare riferimento a questo file in una delle azioni del CodeCatalyst flusso di lavoro Amazon, completa la seguente procedura.

**Nota**  
Consulta anche [Riferimento ai file del repository di origine](workflows-sources-reference-files.md).

------
#### [ Visual ]

*Non disponibile. Scegli YAML per visualizzare le istruzioni YAML.*

------
#### [ YAML ]

**Per fare riferimento ai file in un artefatto (editor YAML)**

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.

1. Scegli **Modifica**.

1. Scegli **YAML**.

1. Nell'azione in cui desideri fare riferimento a un file, aggiungi un codice simile al seguente:

   ```
   Actions:
     My-action:
       Inputs:
         Sources:
           - WorkflowSource
         Artifacts:
           - artifact-name  
       Configuration:
         template: artifact-path/path/to/file.yml
   ```

   Nel codice precedente, sostituisci:
   + *artifact-name*con il nome del manufatto.
   + *artifact-path*con un valore della tabella seguente.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codecatalyst/latest/userguide/workflows-working-artifacts-refer-files.html)

   Per alcuni esempi, consulta [Esempi di manufatti](workflows-working-artifacts-ex.md).
**Nota**  
È possibile omettere *artifact-path* e specificare semplicemente il percorso del file relativo alla directory principale dell'artefatto se:  
L'azione in cui includi il riferimento include solo un elemento sottostante `Inputs` (ad esempio, include un elemento di input e nessuna fonte).
Il file a cui vuoi fare riferimento si trova nell'input principale. L'*input principale* è il`WorkflowSource`, o il primo elemento di input elencato, se non esiste. `WorkflowSource`

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.**

------

# Scaricamento di artefatti
<a name="workflows-download-workflow-outputs"></a>

Puoi scaricare e ispezionare gli artefatti generati dalle azioni del tuo CodeCatalyst flusso di lavoro Amazon per la risoluzione dei problemi. Esistono due tipi di artefatti che puoi scaricare:
+ **Artefatti di origine**: un artefatto che contiene un'istantanea del contenuto del repository di origine così com'era all'avvio dell'esecuzione.
+ **Artefatti del flusso di lavoro: un artefatto** definito nella proprietà del file di configurazione del flusso di lavoro. `Outputs`

**Per scaricare gli artefatti generati dal 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. 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, scegli **Artefatti**.

1. **Accanto a un artefatto, scegli Scarica.** Viene scaricato un file di archivio. Il nome del file è composto da sette caratteri casuali.

1. Estrai l'archivio utilizzando un'utilità di estrazione dell'archivio di tua scelta.

# Specificare la versione dell'azione da utilizzare
<a name="workflows-action-versions"></a>

Per impostazione predefinita, quando aggiungi un'azione a un flusso di lavoro, Amazon CodeCatalyst aggiunge la versione completa al file di definizione del flusso di lavoro utilizzando il formato:

 `vmajor.minor.patch` 

Esempio:

```
My-Build-Action:
  Identifier: aws/build@v1.0.0
```

Puoi abbreviare la versione completa nella `Identifier` proprietà in modo che il flusso di lavoro utilizzi sempre l'ultima versione secondaria o patch dell'azione.

Ad esempio, se si specifica:

```
My-CloudFormation-Action:
  Identifier: aws/cfn-deploy@v1.0
```

... e l'ultima versione della patch è`1.0.4`, allora l'azione utilizzerà`1.0.4`. Se viene rilasciata una versione successiva, ad esempio`1.0.5`, l'azione verrà utilizzata`1.0.5`. Se viene rilasciata una versione secondaria, ad esempio`1.1.0`, l'azione continuerà a essere utilizzata`1.0.5`.

Per istruzioni dettagliate su come specificare le versioni, consultate uno dei seguenti argomenti.

Utilizza le seguenti istruzioni per indicare la versione di un'azione che desideri venga utilizzata dal flusso di lavoro. È possibile specificare la versione principale o secondaria più recente o una versione di patch specifica.

Si consiglia di utilizzare la versione secondaria o la patch più recente di un'azione.

------
#### [ Visual ]

 *Non disponibile. Scegli YAML per visualizzare le istruzioni YAML.* 

------
#### [ YAML ]

**Per configurare un flusso di lavoro per utilizzare la versione più recente di un'azione o una versione di patch specifica**

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 l'azione di cui desideri modificare la versione.

1. Trova la `Identifier` proprietà dell'azione e imposta la versione su una delle seguenti:
   + action-identifier @v*major*: utilizzate questa sintassi per fare in modo che il flusso di lavoro utilizzi una versione principale specifica e consentire la scelta automatica delle versioni secondarie e delle patch più recenti.
   + identificatore di azione @v. *major* *minor*— Utilizzate questa sintassi per fare in modo che il flusso di lavoro utilizzi una versione secondaria specifica e consentite la scelta automatica dell'ultima versione della patch.
   + identificatore di azione @v. *major* *minor*. *patch* — Utilizzate questa sintassi per fare in modo che il flusso di lavoro utilizzi una versione di patch specifica.
**Nota**  
Se non sei sicuro delle versioni disponibili, consulta[Elenco delle versioni action disponibili](workflows-action-versions-determine.md).
**Nota**  
Non puoi omettere la versione principale.

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.**

------

# Elenco delle versioni action disponibili
<a name="workflows-action-versions-determine"></a>

Utilizza le seguenti istruzioni per determinare quali versioni di un'azione sono disponibili per l'uso in un flusso di lavoro.

------
#### [ Visual ]

**Per determinare quali versioni di azione sono disponibili**

1. Apri la CodeCatalyst console all'[indirizzo https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Scegliere il progetto.

1. Trova l'azione di cui desideri visualizzare le versioni:

   1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**

   1. Scegli il nome di qualsiasi flusso di lavoro o creane uno. Per informazioni sulla creazione di un flusso di lavoro, consulta[Creazione di un flusso di lavoro](workflows-create-workflow.md).

   1. Scegli **Modifica**.

   1. In alto a sinistra, scegli **\$1 Azioni** per aprire il catalogo delle azioni.

   1. Nell'elenco a discesa, scegli **Amazon CodeCatalyst** per visualizzare CodeCatalyst, CodeCatalyst Labs e le azioni di terze parti oppure scegli di visualizzare le azioni **GitHub**curate. GitHub

   1. Cerca un'azione e scegline il nome. Non scegliere il segno più (**\$1**).

      Vengono visualizzati i dettagli sull'azione.

1. Nella finestra di dialogo dei dettagli dell'azione, in alto a destra, scegli l'elenco a discesa **Versioni** per visualizzare un elenco delle versioni disponibili dell'azione.

------
#### [ YAML ]

 *Non disponibile. Scegli «visivo» per visualizzare le istruzioni dell'editor visivo.* 

------

# Visualizzazione del codice sorgente di un'azione
<a name="workflows-view-source"></a>

Puoi visualizzare il codice sorgente di un'azione per assicurarti che non contenga codice rischioso, vulnerabilità di sicurezza o altri difetti.

[Utilizza le seguenti istruzioni per visualizzare il codice sorgente di un'[CodeCatalyst](workflows-actions.md#workflows-actions-types-cc)azione di [CodeCatalyst Labs](workflows-actions.md#workflows-actions-types-cc-labs) o di terze parti.](workflows-actions.md#workflows-actions-types-3p)

**Nota**  
Per visualizzare il codice sorgente di un'[GitHubazione](workflows-actions.md#workflows-actions-types-github), vai alla pagina dell'azione nel [GitHub Marketplace](https://github.com/marketplace/actions). La pagina include un link all'archivio dell'azione, dove puoi trovare il codice sorgente dell'azione.

**Nota**  
Non è possibile visualizzare il codice sorgente delle seguenti CodeCatalyst azioni: [build](build-workflow-actions.md), [test](test-workflow-actions.md), [GitHub Actions](integrations-github-action-add.md).

**Nota**  
AWS non supporta né garantisce il codice d'azione di GitHub Actions o le azioni di terze parti.<a name="workflows-to-view-source-cc"></a>

**Per visualizzare il codice sorgente di un'azione**

1. Apri la CodeCatalyst console all'[indirizzo https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Scegliere il progetto.

1. Trova l'azione di cui desideri visualizzare il codice:

   1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**

   1. Scegli il nome di qualsiasi flusso di lavoro o creane uno. Per informazioni sulla creazione di un flusso di lavoro, consulta[Creazione di un flusso di lavoro](workflows-create-workflow.md).

   1. Scegli **Modifica**.

   1. In alto a sinistra, scegli **\$1 Azioni** per aprire il catalogo delle azioni.

   1. Nell'elenco a discesa, scegli **Amazon CodeCatalyst** to view CodeCatalyst, CodeCatalyst Labs e azioni di terze parti.

   1. Cerca un'azione e scegline il nome. Non scegliere il segno più (**\$1**).

      Vengono visualizzati i dettagli sull'azione.

1. Nella finestra di dialogo dei dettagli dell'azione, nella parte inferiore, scegli **Scarica**.

   Viene visualizzata una pagina che mostra il bucket Amazon S3 in cui risiede il codice sorgente dell'azione. Per informazioni su Amazon S3, consulta [What is Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)? nella *Guida per l'utente di Amazon Simple Storage Service*.

1. Controlla il codice per assicurarti che soddisfi le tue aspettative in termini di qualità e sicurezza. 

# Integrazione con GitHub Actions
<a name="integrations-github-actions"></a>

Un'*GitHub azione* è molto simile a un'[CodeCatalyst azione](workflows-actions.md#workflows-actions-types-cc), tranne per il fatto che è stata sviluppata per essere utilizzata con i flussi GitHub di lavoro. Per informazioni dettagliate sulle GitHub azioni, consulta la documentazione relativa [GitHub alle azioni](https://docs.github.com/en/actions).

È possibile utilizzare GitHub le azioni insieme alle CodeCatalyst azioni native in un CodeCatalyst flusso di lavoro.

Esistono due modi per aggiungere un' GitHub azione a un CodeCatalyst flusso di lavoro:
+ Puoi selezionare l' GitHub azione da un elenco curato nella CodeCatalyst console. Sono disponibili diverse GitHub azioni popolari. Per ulteriori informazioni, consulta [Aggiungere un'azione curata GitHub](integrations-github-action-add-curated.md).
+ Se l' GitHub azione che desideri utilizzare non è disponibile nella CodeCatalyst console, puoi aggiungerla utilizzando un'azione **GitHub Azioni**.

  Un'azione ***GitHub Actions*** è un'*CodeCatalyst azione* che racchiude un' GitHub azione e la rende compatibile con CodeCatalyst i flussi di lavoro.

  [Ecco un esempio di azione **GitHub Actions** che completa l'azione Super-Linter:](https://github.com/marketplace/actions/super-linter) GitHub

  ```
  Actions:
    GitHubAction:
      Identifier: aws/github-actions-runner@v1
      Configuration:
        Steps:
          - name: Lint Code Base
            uses: github/super-linter@v4
            env:
              VALIDATE_ALL_CODEBASE: "true"
              DEFAULT_BRANCH: main
  ```

  Nel codice precedente, l'azione CodeCatalyst **GitHub Actions** (identificata da`aws/github-actions-runner@v1`) racchiude l'azione Super-Linter (identificata da), `github/super-linter@v4` facendola funzionare in un flusso di lavoro. CodeCatalyst 

  Per ulteriori informazioni, consulta [Aggiungere l'GitHub azione «Azioni»](integrations-github-action-add.md).

**Tutte le GitHub azioni, curate e non, devono essere racchiuse all'interno di un'GitHub azione Actions (), come mostrato nell'esempio precedente.** `aws/github-actions-runner@v1` Il wrapper è necessario per il corretto funzionamento dell'azione. 

**Topics**
+ [In che modo le GitHub azioni sono diverse dalle CodeCatalyst azioni?](#integrations-github-actions-how-different)
+ [GitHub Le azioni possono interagire con altre CodeCatalyst azioni nel flusso di lavoro?](#integrations-github-actions-interactions.title)
+ [Quali GitHub azioni posso usare?](#integrations-github-actions-supported)
+ [Limitazioni delle GitHub azioni in CodeCatalyst](#integrations-github-actions-limitations)
+ [Come faccio ad aggiungere un' GitHub azione (passaggi di alto livello)?](#integrations-github-actions-how-to)
+ [L' GitHub azione viene eseguita GitHub?](#integrations-github-actions-where-it-runs)
+ [Posso usare anche i GitHub flussi di lavoro?](#integrations-github-actions-workflows-support.title)
+ [Immagine di runtime utilizzata dall'GitHub azione «Azioni»](#integrations-github-actions-runtime)
+ [Tutorial: codice Lint usando un' GitHub azione](integrations-github-action-tutorial.md)
+ [Aggiungere l'GitHub azione «Azioni»](integrations-github-action-add.md)
+ [Aggiungere un'azione curata GitHub](integrations-github-action-add-curated.md)
+ [Esportazione dei parametri GitHub di output](integrations-github-action-export.md)
+ [Parametri di GitHub output di riferimento](integrations-github-action-referencing.md)
+ [GitHub Azione 'Azioni' YAML](github-action-ref.md)

## In che modo le GitHub azioni sono diverse dalle CodeCatalyst azioni?
<a name="integrations-github-actions-how-different"></a>

GitHub Le azioni utilizzate all'interno di un CodeCatalyst flusso di lavoro non hanno lo stesso livello di accesso e integrazione AWS e CodeCatalyst le stesse funzionalità (come [ambienti](deploy-environments.md) e [problemi](issues.md)) CodeCatalyst delle azioni.

## GitHub Le azioni possono interagire con altre CodeCatalyst azioni nel flusso di lavoro?
<a name="integrations-github-actions-interactions.title"></a>

Sì. Ad esempio, GitHub le azioni possono utilizzare variabili prodotte da altre CodeCatalyst azioni come input e possono anche condividere parametri e artefatti di output con CodeCatalyst le azioni. Per ulteriori informazioni, consultare [Esportazione dei parametri GitHub di output](integrations-github-action-export.md) e [Parametri di GitHub output di riferimento](integrations-github-action-referencing.md).

## Quali GitHub azioni posso usare?
<a name="integrations-github-actions-supported"></a>

Puoi utilizzare qualsiasi GitHub azione disponibile tramite la CodeCatalyst console e qualsiasi GitHub azione disponibile nel [GitHubMarketplace](https://github.com/marketplace/actions). Se decidi di utilizzare un' GitHub azione dal Marketplace, tieni presente le seguenti [limitazioni](#integrations-github-actions-limitations).

## Limitazioni delle GitHub azioni in CodeCatalyst
<a name="integrations-github-actions-limitations"></a>
+ GitHub Le azioni non possono essere utilizzate con il tipo di [calcolo CodeCatalyst Lambda](workflows-working-compute.md#compute.types).
+ GitHub Le azioni vengono eseguite sull'immagine Docker dell'ambiente di runtime di [novembre 2022](build-images.md#build.previous-image), che include strumenti precedenti. Per ulteriori informazioni sull'immagine e sugli strumenti, consulta. [Specificazione delle immagini dell'ambiente di runtime](build-images.md)
+ GitHub Le azioni che si basano internamente sul [`github`contesto](https://docs.github.com/en/actions/learn-github-actions/contexts#github-context) o che fanno riferimento GitHub a risorse specifiche non funzioneranno. CodeCatalyst Ad esempio, le seguenti azioni non funzioneranno in: CodeCatalyst
  + Azioni che tentano di aggiungere, modificare o aggiornare GitHub risorse. Gli esempi includono azioni che aggiornano le richieste pull o creano problemi in GitHub.
  + Quasi tutte le azioni elencate in [https://github.com/actions.](https://github.com/actions)
+ GitHub Le azioni che sono [azioni del contenitore Docker](https://docs.github.com/en/actions/creating-actions/about-custom-actions#docker-container-actions) funzioneranno, ma devono essere eseguite dall'utente Docker predefinito (root). Non eseguire l'azione come utente 1001. (Al momento della scrittura, l'utente 1001 lavora in GitHub, ma non in CodeCatalyst.) Per ulteriori informazioni, consulta l'argomento [USER](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions#user) nel [supporto di Dockerfile](https://docs.github.com/en/actions/creating-actions/dockerfile-support-for-github-actions) per Actions. GitHub 

Per un elenco delle GitHub azioni disponibili tramite la CodeCatalyst console, consulta. [Aggiungere un'azione curata GitHub](integrations-github-action-add-curated.md)

## Come faccio ad aggiungere un' GitHub azione (passaggi di alto livello)?
<a name="integrations-github-actions-how-to"></a>

I passaggi di alto livello per aggiungere un' GitHub azione a un CodeCatalyst flusso di lavoro sono i seguenti:

1. Nel tuo CodeCatalyst progetto, **crei un flusso di lavoro**. Il flusso di lavoro è il luogo in cui definisci come creare, testare e distribuire l'applicazione. Per ulteriori informazioni, consulta [Guida introduttiva ai flussi di lavoro](workflows-getting-started.md).

1. Nel flusso di lavoro, **aggiungi un'azione curata o aggiungi l' GitHub azione GitHub ** **Azioni**.

1. Effettuate una delle seguenti operazioni:
   + Se hai scelto di aggiungere un'azione curata, configurala. Per ulteriori informazioni, consulta [Aggiungere un'azione curata GitHub](integrations-github-action-add-curated.md).
   + Se scegli di aggiungere un'azione non curata, all'interno dell'azione **GitHubAzioni**, **incolli il codice YAML dell' GitHub azione**. Puoi trovare questo codice nella pagina dei dettagli dell' GitHubazione scelta nel [GitHubMarketplace](https://github.com/marketplace/actions). Probabilmente dovrai modificare leggermente il codice per farlo funzionare CodeCatalyst. Per ulteriori informazioni, consulta [Aggiungere l'GitHub azione «Azioni»](integrations-github-action-add.md).

1. (Facoltativo) All'interno del flusso di lavoro, **aggiungi altre azioni come le azioni** di compilazione e test. Per ulteriori informazioni, consulta [Crea, testa e distribuisci con i flussi di lavoroCrea, testa e distribuisci con i flussi di lavoro](workflow.md).

1. **Il flusso di lavoro viene avviato** manualmente o automaticamente tramite un trigger. Il flusso di lavoro esegue l' GitHub azione e qualsiasi altra azione del flusso di lavoro. Per ulteriori informazioni, consulta [Avvio manuale dell’esecuzione di un flusso di lavoro](workflows-manually-start.md).

Per i passaggi dettagliati, consulta:
+ [Aggiungere un'azione curata GitHub](integrations-github-action-add-curated.md).
+ [Aggiungere l'GitHub azione «Azioni»](integrations-github-action-add.md).

## L' GitHub azione viene eseguita GitHub?
<a name="integrations-github-actions-where-it-runs"></a>

No. L' GitHub azione viene eseguita utilizzando CodeCatalyst l'[immagine CodeCatalyst dell'ambiente di runtime](workflows-working-compute.md).

## Posso usare anche i GitHub flussi di lavoro?
<a name="integrations-github-actions-workflows-support.title"></a>

No.

## Immagine di runtime utilizzata dall'GitHub azione «Azioni»
<a name="integrations-github-actions-runtime"></a>

L'azione CodeCatalyst **GitHub Actions** viene eseguita su un'[immagine del novembre 2022](build-images.md#build.previous-image). Per ulteriori informazioni, consulta [Immagini attive](build-images.md#build-curated-images).

# Tutorial: codice Lint usando un' GitHub azione
<a name="integrations-github-action-tutorial"></a>

In questo tutorial, aggiungi l'[ GitHub azione Super-Linter](https://github.com/marketplace/actions/super-linter) a un flusso di lavoro Amazon. CodeCatalyst L'azione Super-Linter ispeziona il codice, trova le aree in cui il codice presenta errori, problemi di formattazione e costrutti sospetti, quindi invia i risultati alla console). CodeCatalyst Dopo aver aggiunto il linter al flusso di lavoro, esegui il flusso di lavoro per lint un'applicazione Node.js di esempio (). `app.js` Quindi risolvete i problemi segnalati ed eseguite nuovamente il flusso di lavoro per verificare se le correzioni hanno funzionato.

**Suggerimento**  
[Prendi in considerazione l'utilizzo di Super-Linter per linkare file YAML, come i modelli.CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-guide.html)

**Topics**
+ [Prerequisiti](#integrations-github-action-tutorial-prereqs)
+ [Fase 1: Creare un archivio di sorgenti](#integrations-github-action-tutorial-create-source-repo)
+ [Passaggio 2: aggiungere un file app.js](#integrations-github-action-tutorial-add-appjs)
+ [Passaggio 3: Creare un flusso di lavoro che esegua l'azione Super-Linter](#integrations-github-action-tutorial-create-workflow)
+ [Passaggio 4: Risolvi i problemi rilevati da Super-Linter](#integrations-github-action-tutorial-fix-probs)
+ [Eliminazione](#integrations-github-action-tutorial-cleanup)

## Prerequisiti
<a name="integrations-github-action-tutorial-prereqs"></a>

Prima di iniziare, avrai bisogno di:
+ Uno CodeCatalyst **spazio** con un connesso Account AWS. Per ulteriori informazioni, consulta [Creazione di uno spazio](spaces-create.md).
+ Un progetto vuoto nel tuo CodeCatalyst spazio chiamato`codecatalyst-linter-project`. Scegli l'opzione **Inizia da zero** per creare questo progetto.

  ```
  ```

  Per ulteriori informazioni, consulta [Creare un progetto vuoto in Amazon CodeCatalyst](projects-create.md#projects-create-empty).

## Fase 1: Creare un archivio di sorgenti
<a name="integrations-github-action-tutorial-create-source-repo"></a>

In questo passaggio, si crea un repository di origine in. CodeCatalyst Utilizzerai questo repository per archiviare il file sorgente dell'applicazione di esempio`app.js`, per questo tutorial.

Per ulteriori informazioni sui repository dei sorgenti, consulta. [Creazione di un repository di sorgenti](source-repositories-create.md)

**Per creare un archivio di sorgenti**

1. Apri la CodeCatalyst console all'indirizzo [https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Vai al tuo progetto,`codecatalyst-linter-project`.

1. Nel riquadro di navigazione, scegli **Codice**, quindi scegli **Archivi di origine.** 

1. Scegli **Aggiungi repository**, quindi scegli **Crea** repository.

1. Nel **nome del repository, inserisci:**

   ```
   codecatalyst-linter-source-repository
   ```

1. Scegli **Create** (Crea).

## Passaggio 2: aggiungere un file app.js
<a name="integrations-github-action-tutorial-add-appjs"></a>

In questo passaggio, aggiungi un `app.js` file al tuo repository di origine. `app.js`Contiene un codice di funzione che contiene alcuni errori che il linter troverà.

**Per aggiungere il file app.js**

1. Nella CodeCatalyst console, scegli il tuo progetto,`codecatalyst-linter-project`.

1. Nel riquadro di navigazione, scegli **Codice**, quindi scegli **Archivi di origine.**

1. Dall'elenco dei repository di origine, scegli il tuo repository,. `codecatalyst-linter-source-repository`

1. In **File**, scegli **Crea** file.

1. Nella casella di testo, inserisci il seguente codice:

   ```
   // const axios = require('axios')
   // const url = 'http://checkip.amazonaws.com/';
   let response;
   /**
    *
    * Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format
    * @param {Object} event - API Gateway Lambda Proxy Input Format
    *
    * Context doc: https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-context.html 
    * @param {Object} context
    *
    * Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
    * @returns {Object} object - API Gateway Lambda Proxy Output Format
    *
    */
   exports.lambdaHandler = async (event, context) => {
     try {
       // const ret = await axios(url);
       response = {
         statusCode: 200,
         'body': JSON.stringify({
           message: 'hello world'
           // location: ret.data.trim()
         })
       }
     } catch (err) {
       console.log(err)
       return err
     }
   
       return response
   }
   ```

1. Per **Nome file**, immettere`app.js`. Mantieni le altre opzioni predefinite.

1. Scegli **Applica**.

   Ora hai creato un file chiamato`app.js`.

## Passaggio 3: Creare un flusso di lavoro che esegua l'azione Super-Linter
<a name="integrations-github-action-tutorial-create-workflow"></a>

In questo passaggio, crei un flusso di lavoro che esegua l'azione Super-Linter quando invii il codice al tuo repository di origine. Il flusso di lavoro è costituito dai seguenti elementi costitutivi, definiti in un file YAML:
+ **Un trigger**: questo trigger avvia l'esecuzione automatica del flusso di lavoro quando invii una modifica al tuo repository di origine. Per ulteriori informazioni sui trigger, consulta [L'avvio di un flusso di lavoro viene eseguito automaticamente utilizzando i trigger](workflows-add-trigger.md).
+ **Un'GitHub azione «Azioni»: all'attivazione, l'azione **GitHub Azioni**** esegue l'azione Super-Linter, che a sua volta ispeziona tutti i file nel repository di origine. Se il linter rileva un problema, l'azione del flusso di lavoro fallisce. 

**Per creare un flusso di lavoro che esegua l'azione Super-Linter**

1. Nella CodeCatalyst console, scegli il tuo progetto,. `codecatalyst-linter-project`

1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.** 

1. **Scegli Crea flusso di lavoro.**

1. Per **Source repository**, scegli`codecatalyst-linter-source-repository`.

1. Per **Branch**, scegli`main`.

1. Scegli **Create** (Crea).

1. Elimina il codice di esempio YAML.

1. Aggiungi il seguente YAML:

   ```
   Name: codecatalyst-linter-workflow
   SchemaVersion: "1.0"
   Triggers:
     - Type: PUSH
       Branches:
         - main
   Actions:
     SuperLinterAction:
       Identifier: aws/github-actions-runner@v1
       Configuration:
         Steps:
           github-action-code
   ```

   Nel codice precedente, sostituiscilo *github-action-code* con il codice d'azione Super-Linter, come indicato nei seguenti passaggi di questa procedura.

1. Vai alla [pagina Super-Linter](https://github.com/marketplace/actions/super-linter) nel Marketplace. GitHub 

1. In `steps:` (minuscolo), trova il codice e incollalo nel CodeCatalyst flusso di lavoro sotto (maiuscolo). `Steps:`

   Modifica il codice GitHub Action per renderlo conforme agli CodeCatalyst standard, come mostrato nel codice seguente.

   Il tuo CodeCatalyst flusso di lavoro ora è simile a questo:

   ```
   Name: codecatalyst-linter-workflow
   SchemaVersion: "1.0"
   Triggers:
     - Type: PUSH
       Branches:
         - main
   Actions:
     SuperLinterAction:
       Identifier: aws/github-actions-runner@v1
       Configuration:
         Steps:
           - name: Lint Code Base
             uses: github/super-linter@v4
             env:
               VALIDATE_ALL_CODEBASE: "true"
               DEFAULT_BRANCH: main
   ```

1. (Facoltativo) Scegli **Convalida** per assicurarti che il codice YAML sia valido prima di eseguire il commit.

1. **Scegli **Commit**, inserisci un **messaggio di Commit**, seleziona il tuo `codecatalyst-linter-source-repository` **Repository** e scegli nuovamente Commit.**

   Ora hai creato un flusso di lavoro. L'esecuzione di un flusso di lavoro viene avviata automaticamente a causa del trigger definito nella parte superiore del flusso di lavoro.

**Per visualizzare il flusso di lavoro in corso**

1. **Nel riquadro di navigazione, scegli **CI/CD**, quindi scegli Flussi di lavoro.**

1. Scegli il flusso di lavoro che hai appena creato:. `codecatalyst-linter-workflow`

1. Nel diagramma del flusso di lavoro, scegli **SuperLinterAction**.

1. Attendi che l'azione fallisca. Questo errore è previsto perché il linter ha riscontrato problemi nel codice.

1. Lascia la CodeCatalyst console aperta e vai a. [Passaggio 4: Risolvi i problemi rilevati da Super-Linter](#integrations-github-action-tutorial-fix-probs)

## Passaggio 4: Risolvi i problemi rilevati da Super-Linter
<a name="integrations-github-action-tutorial-fix-probs"></a>

Super-Linter dovrebbe aver riscontrato problemi nel `app.js` codice e nel `README.md` file incluso nel repository dei sorgenti.

**Per risolvere i problemi rilevati da Linter**

1. Nella CodeCatalyst console, scegli la scheda **Registri**, quindi scegli **Lint** Code Base.

   Vengono visualizzati i registri generati dall'azione Super-Linter.

1. Nei log di Super-Linter, scorri verso il basso fino alla riga 90, dove trovi l'inizio dei problemi. Sembrano simili ai seguenti: 

   ```
   /github/workspace/hello-world/app.js:3:13: Extra semicolon.
   /github/workspace/hello-world/app.js:9:92: Trailing spaces not allowed.
   /github/workspace/hello-world/app.js:21:7: Unnecessarily quoted property 'body' found.
   /github/workspace/hello-world/app.js:31:1: Expected indentation of 2 spaces but found 4.
   /github/workspace/hello-world/app.js:32:2: Newline required at end of file but not found.
   ```

1. Correggi `app.js` e `README.md` inserisci le modifiche nel tuo archivio di origine e conferma le modifiche. 
**Suggerimento**  
Per risolvere il problema`README.md`, aggiungi `markdown` al blocco di codice, in questo modo:  

   ```
   ```markdown
   Setup examples:
   ...
   ```
   ```

   Le modifiche avviano automaticamente un altro flusso di lavoro. Attendi il completamento del flusso di lavoro. Se hai risolto tutti i problemi, il flusso di lavoro dovrebbe avere esito positivo.

## Eliminazione
<a name="integrations-github-action-tutorial-cleanup"></a>

Pulisci CodeCatalyst per rimuovere le tracce di questo tutorial dal tuo ambiente.

**Per pulire CodeCatalyst**

1. Apri la CodeCatalyst console all'[indirizzo https://codecatalyst.aws/](https://codecatalyst.aws/).

1. Elimina`codecatalyst-linter-source-repository`.

1. Eliminare`codecatalyst-linter-workflow`.

In questo tutorial, hai imparato come aggiungere l' GitHub azione Super-Linter a un CodeCatalyst flusso di lavoro per inserire del codice.

# Aggiungere l'GitHub azione «Azioni»
<a name="integrations-github-action-add"></a>

Un'azione ***GitHub Actions*** è un'*CodeCatalyst azione che completa un' GitHub azione* e la rende compatibile con i flussi di lavoro. CodeCatalyst 

Per ulteriori informazioni, consulta [Integrazione con GitHub Actions](integrations-github-actions.md).

Per aggiungere l'azione **GitHub Azioni** a un flusso di lavoro, segui questi passaggi.

**Suggerimento**  
Per un tutorial che mostra come utilizzare l'azione **GitHub Azioni**, consulta[Tutorial: codice Lint usando un' GitHub azione](integrations-github-action-tutorial.md).

------
#### [ Visual ]

**Per aggiungere l'GitHub azione «Azioni» 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. In alto a sinistra, scegli **\$1 Azioni** per aprire il catalogo delle azioni.

1. Dall'elenco a discesa, scegli. **GitHub**

1. Cercate l'azione **GitHub Azioni** ed effettuate una delle seguenti operazioni:
   + Scegli il segno più (**\$1**) per aggiungere l'azione al diagramma del flusso di lavoro e apri il relativo riquadro di configurazione.

     Or
   + Scegli **GitHub Azioni**. Viene visualizzata la finestra di dialogo con i dettagli dell'azione. In questa finestra di dialogo:
     + (Facoltativo) Scegliete **Visualizza sorgente** per [visualizzare il codice sorgente dell'azione](workflows-view-source.md#workflows-view-source.title).
     + Scegli **Aggiungi al flusso di lavoro** per aggiungere l'azione al diagramma del flusso di lavoro e aprire il relativo riquadro di configurazione.

1. Nelle schede **Ingressi** e **Configurazione**, completa i campi in base alle tue esigenze. Per una descrizione di ogni campo, consulta. [GitHub Azione 'Azioni' YAML](github-action-ref.md) Questo riferimento fornisce informazioni dettagliate su ogni campo (e il valore della proprietà YAML corrispondente) così come appaiono sia nell'editor YAML che in quello visivo.

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 l'azione «GitHub Azioni» utilizzando l'editor YAML**

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.

1. Scegli **Modifica**.

1. Scegli **YAML**.

1. In alto a sinistra, scegli **\$1 Azioni per aprire il catalogo delle azioni**.

1. Dall'elenco a discesa, scegli. **GitHub**

1. Cercate l'azione **GitHub Azioni** ed effettuate una delle seguenti operazioni:
   + Scegli il segno più (**\$1**) per aggiungere l'azione al diagramma del flusso di lavoro e apri il relativo riquadro di configurazione.

     Or
   + Scegli **GitHub Azioni**. Viene visualizzata la finestra di dialogo con i dettagli dell'azione. In questa finestra di dialogo:
     + (Facoltativo) Scegliete **Visualizza sorgente** per [visualizzare il codice sorgente dell'azione](workflows-view-source.md#workflows-view-source.title).
     + Scegli **Aggiungi al flusso di lavoro** per aggiungere l'azione al diagramma del flusso di lavoro e aprire il relativo riquadro di configurazione.

1. Modifica le proprietà del codice YAML in base alle tue esigenze. Una spiegazione di ogni proprietà disponibile è fornita in. [GitHub Azione 'Azioni' YAML](github-action-ref.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.**

------

## Definizione GitHub dell'azione 'Azioni'
<a name="integrations-github-action-add-definition"></a>

L'azione **GitHub Actions** è definita come un insieme di proprietà YAML all'interno del file di definizione del flusso di lavoro. Per informazioni su queste proprietà, vedere [GitHub Azione 'Azioni' YAML](github-action-ref.md) in. [Definizione YAML del flusso di lavoro](workflow-reference.md)

# Aggiungere un'azione curata GitHub
<a name="integrations-github-action-add-curated"></a>

Un'* GitHub azione curata* è un' GitHub azione resa disponibile nella CodeCatalyst console e funge da esempio di come utilizzare un' GitHub azione all'interno di un CodeCatalyst flusso di lavoro.

 GitHub Le azioni curate sono racchiuse nell'[azione CodeCatalyst -authored **GitHub Actions**](integrations-github-action-add.md), identificata dall'identificatore. `aws/github-actions-runner@v1` [Ad esempio, ecco come si presenta la versione curata di GitHub Action, OSS: TruffleHog ](https://github.com/marketplace/actions/trufflehog-oss) 

```
Actions:
  TruffleHogOSS_e8:
    Identifier: aws/github-actions-runner@v1
    Inputs:
      Sources:
        - WorkflowSource # This specifies that the action requires this Workflow as a source
    Configuration:
      Steps:
        - uses: trufflesecurity/trufflehog@v3.16.0
          with:
            path: ' ' # Required; description: Repository path
            base: ' ' # Required; description: Start scanning from here (usually main branch).
            head: ' ' # Optional; description: Scan commits until here (usually dev branch).
            extra_args: ' ' # Optional; description: Extra args to be passed to the trufflehog cli.
```

Nel codice precedente, l'azione CodeCatalyst **GitHub Actions** (identificata da`aws/github-actions-runner@v1`) racchiude l'azione TruffleHog OSS (identificata da`trufflesecurity/trufflehog@v3.16.0`), facendola funzionare in un flusso di lavoro. CodeCatalyst 

Per configurare questa azione, devi sostituire le stringhe vuote sotto `with:` con i tuoi valori. Esempio:

```
Actions:
  TruffleHogOSS_e8:
    Identifier: aws/github-actions-runner@v1
    Inputs:
      Sources:
        - WorkflowSource # This specifies that the action requires this Workflow as a source
    Configuration:
      Steps:
        - uses: trufflesecurity/trufflehog@v3.16.0
          with:
            path: ./
            base: main # Required; description: Start scanning from here (usually main branch).
            head: HEAD # Optional; description: Scan commits until here (usually dev branch).
            extra_args: '‐‐debug ‐‐only-verified' # Optional; description: Extra args to be passed to the trufflehog cli.
```

Per aggiungere un' GitHub azione curata a un flusso di lavoro, utilizzate la procedura seguente. Per informazioni generali sull'utilizzo GitHub delle azioni in un CodeCatalyst flusso di lavoro, consulta[Integrazione con GitHub Actions](integrations-github-actions.md).

**Nota**  
Se non vedi la tua GitHub azione nell'elenco delle azioni curate, puoi comunque aggiungerla al flusso di lavoro utilizzando l'azione **GitHub Azioni**. Per ulteriori informazioni, consulta [Aggiungere l'GitHub azione «Azioni»](integrations-github-action-add.md).

------
#### [ Visual ]

**Per aggiungere un' GitHub azione curata utilizzando l'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. In alto a sinistra, scegli **\$1 Azioni** per aprire il catalogo delle azioni.

1. Dall'elenco a discesa, scegli. **GitHub**

1. Sfoglia o cerca un' GitHub azione ed esegui una delle seguenti operazioni:
   + Scegli il segno più (**\$1**) per aggiungere l'azione al diagramma del flusso di lavoro e apri il relativo riquadro di configurazione.

     Or
   + Scegli il nome dell' GitHub azione. Viene visualizzata la finestra di dialogo con i dettagli dell'azione. In questa finestra di dialogo:
     + (Facoltativo) Scegliete **Visualizza sorgente** per [visualizzare il codice sorgente dell'azione](workflows-view-source.md#workflows-view-source.title).
     + Scegli **Aggiungi al flusso di lavoro** per aggiungere l'azione al diagramma del flusso di lavoro e aprire il relativo riquadro di configurazione.

1. Nelle schede **Ingressi**, **Configurazione** e **Uscite**, completa i campi in base alle tue esigenze. Per una descrizione di ogni campo, vedi. [GitHub Azione 'Azioni' YAML](github-action-ref.md) Questo riferimento fornisce informazioni dettagliate su ogni campo (e il valore della proprietà YAML corrispondente) disponibile per l'azione **GitHubActions**, così come appare sia nell'editor YAML che in quello visivo.

   Per informazioni sulle opzioni di configurazione disponibili per l'Action curata, consulta la relativa documentazione. GitHub

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' GitHub azione curata 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 alto a sinistra, scegli **\$1 Azioni per aprire il catalogo delle azioni**.

1. Dall'elenco a discesa, scegli. **GitHub**

1. Sfoglia o cerca un' GitHub azione ed esegui una delle seguenti operazioni:
   + Scegli il segno più (**\$1**) per aggiungere l'azione al diagramma del flusso di lavoro e apri il relativo riquadro di configurazione.

     Or
   + Scegli il nome dell' GitHub azione. Viene visualizzata la finestra di dialogo con i dettagli dell'azione. In questa finestra di dialogo:
     + (Facoltativo) Scegliete **Visualizza sorgente** per [visualizzare il codice sorgente dell'azione](workflows-view-source.md#workflows-view-source.title).
     + Scegli **Aggiungi al flusso di lavoro** per aggiungere l'azione al diagramma del flusso di lavoro e aprire il relativo riquadro di configurazione.

1. Modifica le proprietà del codice YAML in base alle tue esigenze. Una spiegazione di ogni proprietà disponibile per l'azione **GitHub Azioni** è fornita in. [GitHub Azione 'Azioni' YAML](github-action-ref.md)

   Per informazioni sulle opzioni di configurazione disponibili per l' GitHubAction curata, consulta la relativa documentazione.

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.**

------

# Esportazione dei parametri GitHub di output
<a name="integrations-github-action-export"></a>

È possibile utilizzare [i parametri GitHub di output](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter) nei CodeCatalyst flussi di lavoro.

**Nota**  
Un'altra parola per indicare il *parametro di output* è *variabile*. Poiché GitHub utilizza il termine *parametro di output* nella sua documentazione, useremo anche questo termine.

Utilizzate le seguenti istruzioni per esportare un parametro GitHub di output da un' GitHub azione in modo che sia disponibile per l'uso da parte di altre azioni CodeCatalyst del flusso di lavoro.

**Per esportare un parametro GitHub di output**

1. Apri un flusso di lavoro e scegli **Modifica**. Per ulteriori informazioni, consulta [Creazione di un flusso di lavoro](workflows-create-workflow.md).

1. Nell'azione **GitHub Azioni** che genera il parametro di output che desideri esportare, aggiungi una `Outputs` sezione con una `Variables` proprietà sottostante simile alla seguente:

   ```
   Actions:
     MyGitHubAction:
       Identifier: aws/github-actions-runner@v1
       Outputs:
         Variables:
           - 'step-id_output-name'
   ```

   Sostituisci:
   + *step-id*con il valore della `id:` proprietà nella `steps` sezione dell' GitHub azione.
   + *output-name*con il nome del parametro GitHub di output.

**Esempio**  
L'esempio seguente mostra come esportare un parametro GitHub di output chiamato`SELECTEDCOLOR`.

   ```
   Actions:
     MyGitHubAction:
       Identifier: aws/github-actions-runner@v1
       Outputs:
         Variables:
           - 'random-color-generator_SELECTEDCOLOR'
       Configuration:
         Steps:
           - name: Set selected color
             run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
             id: random-color-generator
   ```

# Parametri di GitHub output di riferimento
<a name="integrations-github-action-referencing"></a>

Utilizzate le seguenti istruzioni per fare riferimento a un parametro GitHub di output.

**Per fare riferimento a un parametro GitHub di output**

1. Completa le fasi descritte in [Esportazione dei parametri GitHub di output](integrations-github-action-export.md).

   Il parametro GitHub di output è ora disponibile per l'uso in altre azioni.

1. Annotate il `Variables` valore del parametro di output. Include un carattere di sottolineatura (\$1).

1. Fate riferimento al parametro di output utilizzando la seguente sintassi:

   ```
   ${action-name.output-name}
   ```

   Sostituire:
   + *action-name*con il nome dell' CodeCatalyst**GitHub azione** che produce il parametro di output (non utilizzate l'`name`o dell' GitHub azione`id`).
   + *output-name*con il `Variables` valore del parametro di output che hai notato in precedenza.

   **Esempio**

   ```
   BuildActionB:
     Identifier: aws/build@v1
     Configuration:
       Steps:
         - Run: echo ${MyGitHubAction.random-color-generator_SELECTEDCOLOR}
   ```

**Esempio con contesto**  
L'esempio seguente mostra come impostare una `SELECTEDCOLOR` variabile`GitHubActionA`, emetterla e quindi farvi riferimento`BuildActionB`.

   ```
   Actions:
     GitHubActionA:
       Identifier: aws/github-actions-runner@v1
       Configuration:
         Steps:
           - name: Set selected color
             run: echo "SELECTEDCOLOR=green" >> $GITHUB_OUTPUT
             id: random-color-generator
       Outputs:
         Variables:
         - 'random-color-generator_SELECTEDCOLOR'
         
      BuildActionB:
       Identifier: aws/build@v1
       Configuration:
         Steps:
           - Run: echo ${GitHubActionA.random-color-generator_SELECTEDCOLOR}
   ```

# GitHub Azione 'Azioni' YAML
<a name="github-action-ref"></a>

Di seguito è riportata la definizione YAML dell'**GitHubazione Actions**.

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).

Scegliete una proprietà YAML nel codice seguente per vederne una descrizione.

**Nota**  
La maggior parte delle proprietà YAML che seguono hanno elementi dell'interfaccia utente corrispondenti nell'editor visuale. **Per cercare un elemento dell'interfaccia utente, 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 action definition starts here.
  action-name:
    Identifier:  aws/github-actions-runner@v1
    DependsOn:
      - dependent-action-name-1
    Compute:
      Fleet: fleet-name
    Timeout: timeout-minutes
    Environment:
      Name: environment-name
      Connections:
        - Name: account-connection-name
          Role: iam-role-name
    Inputs:
      Sources:
        - source-name-1
        - source-name-2
      Artifacts:
        - artifact-name
      Variables:
        - Name: variable-name-1
          Value: variable-value-1
        - Name: variable-name-2
          Value: variable-value-2   
    Outputs:
      Artifacts:
        - Name: output-artifact-1
          Files: 
            - github-output/artifact-1.jar
            - "github-output/build*"
        - Name: output-artifact-2
          Files:
            - github-output/artifact-2.1.jar
            - github-output/artifact-2.2.jar
      Variables:
        - variable-name-1
        - variable-name-2
      AutoDiscoverReports:
        Enabled: true | false
        ReportNamePrefix: AutoDiscovered
        IncludePaths:
          - "**/*"
        ExcludePaths:
          - node_modules/cdk/junit.xml
        SuccessCriteria:
          PassRate: percent
          LineCoverage: percent
          BranchCoverage: percent
          Vulnerabilities:
            Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
            Number: whole-number
      Reports:
        report-name-1:
          Format: format
          IncludePaths:
            - "*.xml"
          ExcludePaths:
            - report2.xml
            - report3.xml
          SuccessCriteria:
            PassRate: percent
            LineCoverage: percent
            BranchCoverage: percent
            Vulnerabilities:
              Severity: CRITICAL|HIGH|MEDIUM|LOW|INFORMATIONAL
              Number: whole-number
    Configuration      
      Steps:
        - github-actions-code
```

## nome dell'azione
<a name="github.name"></a>

(Obbligatorio)

Specificare il nome dell'azione. Tutti i nomi delle azioni devono essere univoci all'interno del flusso di lavoro. I nomi delle azioni 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 azioni.

Interfaccia utente corrispondente: scheda Configurazione/ *action-name*

## Identifier
<a name="github.identifier"></a>

(*action-name*/**Identifier**)

Identifica l'azione. Non modificate questa proprietà a meno che non vogliate cambiare la versione. Per ulteriori informazioni, consulta [Specificare la versione dell'azione da utilizzare](workflows-action-versions.md).

Usa `aws/github-actions-runner@v1` per **GitHuble azioni** Actions.

Interfaccia utente corrispondente: diagramma del flusso di lavoro//*action-name***aws/ @v1 label github-actions-runner**

## DependsOn
<a name="github.depends-on"></a>

(*action-name*/**DependsOn**)

(Facoltativo)

Specificate un'azione, un gruppo di azioni o un gate che deve essere eseguito correttamente per l'esecuzione di questa azione.

Per ulteriori informazioni sulla funzionalità «dipende da», vedere. [Azioni di sequenziamento](workflows-depends-on.md)

**Interfaccia utente corrispondente: scheda Ingressi/Dipende da - opzionale**

## Compute
<a name="github.computename"></a>

(*action-name*/**Compute**)

(Facoltativo)

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

Interfaccia utente corrispondente: *nessuna*

## Fleet
<a name="github.computefleet"></a>

(*action-name*/Compute/**Fleet**)

(Facoltativo)

Specificate la macchina o il parco macchine che eseguiranno il flusso di lavoro o le azioni del flusso di lavoro. Con le flotte on-demand, all'avvio di un'azione, il flusso di lavoro fornisce le risorse necessarie e le macchine vengono distrutte al termine dell'azione. Esempi di flotte on-demand:,. `Linux.x86-64.Large` `Linux.x86-64.XLarge` Per ulteriori informazioni sulle flotte on-demand, vedere. [Proprietà del parco istanze on demand](workflows-working-compute.md#compute.on-demand)

Con le flotte assegnate, puoi configurare una serie di macchine dedicate per eseguire le azioni del flusso di lavoro. Queste macchine rimangono inattive, pronte a elaborare immediatamente le azioni. Per ulteriori informazioni sulle flotte rifornite, vedere. [Proprietà del parco istanze con provisioning](workflows-working-compute.md#compute.provisioned-fleets)

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

Interfaccia utente corrispondente: scheda di configurazione/parco di **calcolo** - opzionale

## Timeout
<a name="github.timeout"></a>

(*action-name*/**Timeout**)

(Facoltativo)

Specificate il periodo di tempo, in minuti (editor YAML) o in ore e minuti (editor visivo), che l'azione può essere eseguita prima CodeCatalyst che termini l'azione. Il minimo è 5 minuti e il massimo è descritto in. [Quote per i flussi di lavoro in CodeCatalyst](workflows-quotas.md) Il timeout predefinito è lo stesso del timeout massimo.

**Interfaccia utente corrispondente: scheda di configurazione/timeout - opzionale**

## Environment
<a name="github.environment"></a>

(*action-name*/**Environment**)

(Facoltativo)

Specificare l' CodeCatalyst ambiente da utilizzare con l'azione. L'azione si connette Account AWS all'Amazon VPC opzionale specificato nell'ambiente scelto. L'azione utilizza il ruolo IAM predefinito specificato nell'ambiente per connettersi a e utilizza il ruolo IAM specificato nella [connessione Amazon VPC](https://docs.aws.amazon.com/codecatalyst/latest/adminguide/managing-vpcs.add.html) per connettersi ad Amazon VPC. Account AWS

**Nota**  
Se il ruolo IAM predefinito non dispone delle autorizzazioni richieste dall'azione, puoi configurare l'azione per utilizzare un ruolo diverso. Per ulteriori informazioni, consulta [Modifica del ruolo IAM di un'azione](deploy-environments-switch-role.md).

Per ulteriori informazioni sugli ambienti, consulta [Implementazione in e Account AWS VPCs](deploy-environments.md) e[Creazione di un ambiente](deploy-environments-creating-environment.md).

**Interfaccia utente corrispondente: scheda di configurazione/ambiente**

## Name
<a name="github.environment.name"></a>

(*action-name*/Environment/**Name**)

(Richiesto se [Environment](#github.environment) incluso)

Specificate il nome di un ambiente esistente che desiderate associare all'azione.

**Interfaccia utente corrispondente: scheda di configurazione/ambiente**

## Connections
<a name="github.environment.connections"></a>

(*action-name*/Environment/**Connections**)

(Facoltativo)

Specificare la connessione dell'account da associare all'azione. È possibile specificare al massimo una connessione a un account in`Environment`.

Se non si specifica una connessione all'account:
+ L'azione utilizza la Account AWS connessione e il ruolo IAM predefinito specificati nell'ambiente della CodeCatalyst console. Per informazioni sull'aggiunta di una connessione all'account e del ruolo IAM predefinito all'ambiente, consulta[Creazione di un ambiente](deploy-environments-creating-environment.md).
+ Il ruolo IAM predefinito deve includere le policy e le autorizzazioni richieste dall'azione. Per determinare quali sono tali politiche e autorizzazioni, consulta la descrizione della proprietà **Role nella documentazione** sulla definizione YAML dell'azione.

Per ulteriori informazioni sulle connessioni degli account, vedere. [Consentire l'accesso alle AWS risorse con connessione Account AWS](ipa-connect-account.md) Per informazioni sull'aggiunta di una connessione tramite account a un ambiente, vedere[Creazione di un ambiente](deploy-environments-creating-environment.md).

Interfaccia utente corrispondente: tab/Environment/What la configurazione è attiva*my-environment*? **/menu a tre punti/ Cambia ruolo**

## Name
<a name="github.environment.connections.name"></a>

(*action-name*/Environment/Connections/**Name**)

(Obbligatorio se incluso[Connections](#github.environment.connections))

Specificare il nome della connessione all'account.

Interfaccia utente corrispondente: tab/Environment/What la configurazione è attiva*my-environment*? **/menu a tre punti/ Cambia ruolo**

## Role
<a name="github.environment.connections.role"></a>

(*action-name*/Environment/Connections/**Role**)

(Obbligatorio se incluso[Connections](#github.environment.connections))

Specificate il nome del ruolo IAM utilizzato da questa azione per accedere e operare in AWS servizi come Amazon S3 e Amazon ECR. Assicurati che questo ruolo venga aggiunto alla tua Account AWS connessione nel tuo spazio. Per aggiungere un ruolo IAM alla connessione di un account, consulta[Aggiunta di ruoli IAM alle connessioni degli account](ipa-connect-account-addroles.md).

Se non specifichi un ruolo IAM, l'azione utilizza il ruolo IAM predefinito elencato nell'[ambiente](deploy-environments.md) nella CodeCatalyst console. Se utilizzi il ruolo predefinito nell'ambiente, assicurati che abbia le seguenti politiche.

**Nota**  
Puoi usare il `CodeCatalystWorkflowDevelopmentRole-spaceName` ruolo con questa azione. Per ulteriori informazioni su questo ruolo, consulta [Creazione del **CodeCatalystWorkflowDevelopmentRole-*spaceName***ruolo per il tuo account e il tuo spazio](ipa-iam-roles.md#ipa-iam-roles-service-create). Tieni presente che il `CodeCatalystWorkflowDevelopmentRole-spaceName` ruolo dispone di autorizzazioni di accesso complete, il che può rappresentare un rischio per la sicurezza. Ti consigliamo di utilizzare questo ruolo solo in tutorial e scenari in cui la sicurezza è meno preoccupante. 

**avvertimento**  
**Limita le autorizzazioni a quelle richieste dall'azione AzioneGitHub .** L'utilizzo di un ruolo con autorizzazioni più ampie potrebbe rappresentare un rischio per la sicurezza.

Interfaccia utente corrispondente: la configurazione tab/Environment/What è attiva? *my-environment* **/menu a tre punti/ Cambia ruolo**

## Inputs
<a name="github.inputs"></a>

(*action-name*/**Inputs**)

(Facoltativo)

La `Inputs` sezione definisce i dati necessari a un'azione durante l'esecuzione di un flusso di lavoro.

**Nota**  
**È consentito un massimo di quattro input (una fonte e tre artefatti) per GitHub azione Actions.** Le variabili non vengono conteggiate per questo totale.

Se è necessario fare riferimento a file che risiedono in input diversi (ad esempio una sorgente e un artefatto), l'input di origine è l'input principale e l'artefatto è l'input secondario. I riferimenti ai file negli input secondari richiedono un prefisso speciale per distinguerli dal primario. Per informazioni dettagliate, vedi [Esempio: riferimento a file in più artefatti](workflows-working-artifacts-ex.md#workflows-working-artifacts-ex-ref-file).

**Interfaccia utente corrispondente: scheda Ingressi**

## Sources
<a name="github.inputs.sources"></a>

(*action-name*/Inputs/**Sources**)

(Facoltativo)

Specificate le etichette che rappresentano i repository di origine che saranno necessari all'azione. Attualmente, l'unica etichetta supportata è`WorkflowSource`, che rappresenta l'archivio di origine in cui è archiviato il file di definizione del flusso di lavoro.

Se si omette una fonte, è necessario specificare almeno un elemento di input in. `action-name/Inputs/Artifacts`

Per ulteriori informazioni sulle origini, consulta [Connessione degli archivi di origine ai flussi di lavoro](workflows-sources.md).

**Interfaccia utente corrispondente: scheda Ingressi/Sorgenti - opzionale**

## Artifacts - input
<a name="github.inputs.artifacts"></a>

(*action-name*/Inputs/**Artifacts**)

(Facoltativo)

Specificate gli artefatti delle azioni precedenti che desiderate fornire come input per questa azione. Questi artefatti devono essere già definiti come artefatti di output nelle azioni precedenti.

Se non si specifica alcun artefatto di input, è necessario specificare almeno un repository di origine in. `action-name/Inputs/Sources`

Per ulteriori informazioni sugli artefatti, inclusi esempi, vedere. [Condivisione di artefatti e file tra azioni](workflows-working-artifacts.md)

**Nota**  
Se l'elenco a discesa **Artifacts - opzionale** non è disponibile (editor visivo) o se si verificano errori durante la convalida di YAML (editor YAML), è possibile che l'azione supporti un solo input. In questo caso, prova a rimuovere l'input sorgente.

Interfaccia utente corrispondente: scheda **Ingressi/Artefatti - opzionale**

## Variables - input
<a name="github.inputs.variables"></a>

(*action-name*/Inputs/**Variables**)

(Facoltativo)

Specificate una sequenza di name/value coppie che definisca le variabili di input che desiderate rendere disponibili all'azione. I nomi delle variabili 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 variabili.

Per ulteriori informazioni sulle variabili, inclusi esempi, vedere[Utilizzo delle variabili nei flussi di lavoro](workflows-working-with-variables.md).

Interfaccia utente corrispondente: scheda **Input/Variabili** - opzionale

## Outputs
<a name="github.outputs"></a>

(*action-name*/**Outputs**)

(Facoltativo)

Definisce i dati emessi dall'azione durante l'esecuzione di un flusso di lavoro.

Interfaccia utente corrispondente: **scheda Output**

## Artifacts - output
<a name="github.outputs.artifacts"></a>

(*action-name*/Outputs/**Artifacts**)

(Facoltativo)

Specificate il nome di un artefatto generato dall'azione. I nomi degli Artifact devono essere univoci all'interno di un flusso di lavoro e sono limitati a caratteri alfanumerici (a-z, A-Z, 0-9) e caratteri di sottolineatura (\$1). Spazi, trattini (-) e altri caratteri speciali non sono consentiti. Non è possibile utilizzare le virgolette per abilitare spazi, trattini e altri caratteri speciali nei nomi degli artefatti di output.

Per ulteriori informazioni sugli artefatti, inclusi esempi, vedere. [Condivisione di artefatti e file tra azioni](workflows-working-artifacts.md)

**Interfaccia utente corrispondente: scheda Outputs/Artifacts**

## Name
<a name="github.outputs.artifacts.name"></a>

(*action-name*/Outputs/Artifacts/**Name**)

(Richiesto se incluso) [Artifacts - output](#github.outputs.artifacts)

Specificate il nome di un artefatto generato dall'azione. I nomi degli Artifact devono essere univoci all'interno di un flusso di lavoro e sono limitati a caratteri alfanumerici (a-z, A-Z, 0-9) e caratteri di sottolineatura (\$1). Spazi, trattini (-) e altri caratteri speciali non sono consentiti. Non è possibile utilizzare le virgolette per abilitare spazi, trattini e altri caratteri speciali nei nomi degli artefatti di output.

Per ulteriori informazioni sugli artefatti, inclusi esempi, vedere. [Condivisione di artefatti e file tra azioni](workflows-working-artifacts.md)

**Interfaccia utente corrispondente: restituisce il nome dell'artefatto/crea l'tab/Artifacts/Addartefatto**

## Files
<a name="github.outputs.artifacts.files"></a>

(*action-name*/Outputs/Artifacts/**Files**)

(Richiesto se incluso) [Artifacts - output](#github.outputs.artifacts)

Specificate i file CodeCatalyst inclusi nell'artefatto generato dall'azione. Questi file vengono generati dall'azione del flusso di lavoro durante l'esecuzione e sono disponibili anche nell'archivio di origine. I percorsi dei file possono risiedere in un repository di origine o in un elemento di un'azione precedente e sono relativi al repository di origine o alla radice dell'elemento. È possibile utilizzare modelli a globo per specificare i percorsi. Esempi:
+ Per specificare un singolo file che si trova nella radice della posizione di creazione o della posizione del repository di origine, usa. `my-file.jar`
+ Per specificare un singolo file in una sottodirectory, usa `directory/my-file.jar` o. `directory/subdirectory/my-file.jar`
+ Per specificare tutti i file, utilizzare`"**/*"`. Il pattern a `**` glob indica che deve corrispondere a un numero qualsiasi di sottodirectory.
+ Per specificare tutti i file e le directory in una directory denominata, usa. `directory` `"directory/**/*"` Il pattern a `**` glob indica che deve corrispondere a un numero qualsiasi di sottodirectory.
+ Per specificare tutti i file in una directory denominata`directory`, ma non nessuna delle sue sottodirectory, usa. `"directory/*"` 

**Nota**  
Se il percorso del file include uno o più asterischi (`*`) o un altro carattere speciale, racchiudi il percorso tra virgolette doppie (). `""` Per ulteriori informazioni sui caratteri speciali, vedere. [Linee guida e convenzioni sulla sintassi](workflow-reference.md#workflow.terms.syntax.conv)

Per ulteriori informazioni sugli artefatti, inclusi esempi, vedere. [Condivisione di artefatti e file tra azioni](workflows-working-artifacts.md)

**Nota**  
Potrebbe essere necessario aggiungere un prefisso al percorso del file per indicare in quale elemento o fonte trovarlo. Per ulteriori informazioni, consultare [Riferimento ai file del repository di origine](workflows-sources-reference-files.md) e [Riferimento ai file in un artefatto](workflows-working-artifacts-refer-files.md).

**Interfaccia utente corrispondente: restituisce tab/Artifacts/Add artefatti/file prodotti dalla build**

## Variables - output
<a name="github.outputs.variables"></a>

(*action-name*/Outputs/**Variables**)

(Facoltativo)

Specificate le variabili che desiderate che l'azione esporti in modo che siano disponibili per l'uso da parte delle azioni successive.

Per ulteriori informazioni sulle variabili, inclusi esempi, vedere[Utilizzo delle variabili nei flussi di lavoro](workflows-working-with-variables.md).

**Interfaccia utente corrispondente: scheda Output/Variabili/ Aggiungi variabile**

## nome-variabile-1
<a name="github.outputs.variables.name"></a>

**(nome-variabile-1) *action-name* /Outputs/Variables**

(Facoltativo)

Specificate il nome di una variabile che desiderate che l'azione esporti. Questa variabile deve essere già definita nella `Steps` sezione `Inputs` o della stessa azione.

Per ulteriori informazioni sulle variabili, inclusi esempi, vedere[Utilizzo delle variabili nei flussi di lavoro](workflows-working-with-variables.md).

**Interfaccia utente corrispondente: tab/Variables/Add variabile/nome degli output**

## AutoDiscoverReports
<a name="github.outputs.autodiscover"></a>

(*action-name*/Outputs/**AutoDiscoverReports**)

(Facoltativo)

Definisce la configurazione per la funzione di individuazione automatica.

Quando abiliti l'individuazione automatica, tutte le CodeCatalyst ricerche `Inputs` passano all'azione e tutti i file generati dall'azione stessa, alla ricerca di report di test, copertura del codice e analisi della composizione del software (SCA). Per ogni report trovato, lo CodeCatalyst trasforma in un report. CodeCatalyst Un *CodeCatalyst report* è un report completamente integrato nel CodeCatalyst servizio e che può essere visualizzato e manipolato tramite la CodeCatalyst console.

**Nota**  
Per impostazione predefinita, la funzione di individuazione automatica ispeziona tutti i file. È possibile limitare i file da ispezionare utilizzando le [IncludePaths](#github.reports.includepaths) proprietà o. [ExcludePaths](#github.reports.excludepaths) 

*Interfaccia utente corrispondente: nessuna*

## Enabled
<a name="github.outputs.autodiscover.enabled"></a>

(*action-name*/Outputs/AutoDiscoverReports/**Enabled**)

(Facoltativo)

Abilita o disabilita la funzione di rilevamento automatico.

I valori validi sono `true` e `false`.

Se `Enabled` viene omesso, l'impostazione predefinita è. `true`

**Interfaccia utente corrispondente: scheda Outputs/Reports/ Rileva automaticamente i report**

## ReportNamePrefix
<a name="github.outputs.autodiscover.reportnameprefix"></a>

(*action-name*/Outputs/AutoDiscoverReports/**ReportNamePrefix**)

(Richiesto se [AutoDiscoverReports](#github.outputs.autodiscover) è incluso e abilitato)

Specificate un prefisso che CodeCatalyst precede tutti i report trovati per assegnare un nome ai report associati. CodeCatalyst Ad esempio, se si specifica un prefisso di `AutoDiscovered` e CodeCatalyst rileva automaticamente due rapporti di test `TestSuiteOne.xml` e`TestSuiteTwo.xml`, i CodeCatalyst report associati verranno denominati e. `AutoDiscoveredTestSuiteOne` `AutoDiscoveredTestSuiteTwo`

**Interfaccia utente corrispondente: Outputs tab/Reports/Automatically discover reports/ Report prefix**

## IncludePaths
<a name="github.reports.includepaths"></a>

(*action-name*/Outputs/AutoDiscoverReports/**IncludePaths**)

Or

(*action-name*/Outputs/Reports/*report-name-1*/**IncludePaths**)

(Richiesto se [AutoDiscoverReports](#github.outputs.autodiscover) è incluso e abilitato o se è incluso) [Reports](#github.configuration.reports)

Specificate i file e i percorsi dei file da CodeCatalyst includere nella ricerca di report non elaborati. Ad esempio, se si specifica`"/test/report/*"`, CodeCatalyst cerca la directory nell'intera [immagine di build](build-images.md) utilizzata dall'azione per cercare la `/test/report/*` directory. Quando trova quella directory, cerca CodeCatalyst i report in quella directory.

**Nota**  
Se il percorso del file include uno o più asterischi (`*`) o altri caratteri speciali, racchiudi il percorso tra virgolette doppie (). `""` Per ulteriori informazioni sui caratteri speciali, vedere. [Linee guida e convenzioni sulla sintassi](workflow-reference.md#workflow.terms.syntax.conv)

Se questa proprietà viene omessa, l'impostazione predefinita è`"**/*"`, ovvero la ricerca include tutti i file in tutti i percorsi.

**Nota**  
Per i report configurati manualmente, `IncludePaths` deve essere presente uno schema a globo che corrisponda a un singolo file.

Interfaccia utente corrispondente:
+ **Percorsi di tab/Reports/Automatically discover reports/'Include/exclude uscita/Includi percorsi**
+ **Gli output tab/Reports/Manually configurano i report/ /'Includi/escludi percorsi'/ Include i percorsi *report-name-1***

## ExcludePaths
<a name="github.reports.excludepaths"></a>

(*action-name*/Outputs/AutoDiscoverReports/**ExcludePaths**)

Or

(*action-name*/Outputs/Reports/*report-name-1*/**ExcludePaths**)

(Facoltativo)

Specificate i file e i percorsi dei file da escludere durante la ricerca di report non elaborati. CodeCatalyst Ad esempio, se si specifica`"/test/my-reports/**/*"`, non CodeCatalyst cercherà i file nella `/test/my-reports/` directory. Per ignorare tutti i file in una directory, utilizzate il pattern `**/*` glob.

**Nota**  
Se il percorso del file include uno o più asterischi (`*`) o altri caratteri speciali, racchiudi il percorso tra virgolette doppie (). `""` Per ulteriori informazioni sui caratteri speciali, vedere. [Linee guida e convenzioni sulla sintassi](workflow-reference.md#workflow.terms.syntax.conv)

Interfaccia utente corrispondente:
+ **Percorsi di tab/Reports/Automatically discover reports/'Include/exclude uscita/ Esclude percorsi**
+ **Gli output tab/Reports/Manually configurano i report/ /'Includi/escludi percorsi'/ Escludi i percorsi *report-name-1***

## SuccessCriteria
<a name="github.reports.successcriteria"></a>

(*action-name*/Outputs/AutoDiscoverReports/**SuccessCriteria**)

Or

(*action-name*/Outputs/Reports/*report-name-1*/**SuccessCriteria**)

(Facoltativo)

Specificate i criteri di successo per i report di test, copertura del codice, analisi della composizione del software (SCA) e analisi statica (SA).

Per ulteriori informazioni, consulta [Configurazione dei criteri di successo per i report](test-config-action.md#test.success-criteria).

Interfaccia utente corrispondente:
+ **I risultati tab/Reports/Automatically scoprono i report/criteri di successo**
+ **Gli output tab/Reports/Manually configurano i report//Criteri di successo *report-name-1***

## PassRate
<a name="github.reports.successcriteria.passrate"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**PassRate**)

Or

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**PassRate**)

(Facoltativo)

Specificate la percentuale di test da superare in un rapporto di prova affinché il CodeCatalyst rapporto associato venga contrassegnato come superato. I valori validi includono i numeri decimali. Ad esempio, `50`, `60.5`. I criteri relativi alla percentuale di superamento vengono applicati solo ai rapporti di prova. Per ulteriori informazioni sui rapporti di prova, vedere[Rapporti dei test](test-workflow-actions.md#test-reports).

Interfaccia utente corrispondente:
+ tab/Reports/Automatically discover reports/Success**Criteri di uscita/Frequenza di passaggio**
+ **Gli output tab/Reports/Manually configurano i report/ /Criteri di successo/ Percentuale di successo *report-name-1***

## LineCoverage
<a name="github.reports.successcriteria.linecoverage"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**LineCoverage**)

Or

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**LineCoverage**)

(Facoltativo)

Specificate la percentuale di righe da coprire in un rapporto sulla copertura del codice affinché il rapporto associato CodeCatalyst venga contrassegnato come superato. I valori validi includono i numeri decimali. Ad esempio, `50`, `60.5`. I criteri di copertura delle linee vengono applicati solo ai report sulla copertura del codice. Per ulteriori informazioni sui rapporti sulla copertura del codice, vedere[Report di copertura del codice](test-workflow-actions.md#test-code-coverage-reports).

Interfaccia utente corrispondente:
+ tab/Reports/Automatically discover reports/Success**Criteri di uscita/Copertura di linea**
+ **Gli output tab/Reports/Manually configurano i report//Criteri di successo/ Copertura di linea *report-name-1***

## BranchCoverage
<a name="github.reports.successcriteria.branchcoverage"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**BranchCoverage**)

Or

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**BranchCoverage**)

(Facoltativo)

Specificate la percentuale di filiali in un rapporto sulla copertura del codice che deve essere coperta affinché il rapporto associato CodeCatalyst venga contrassegnato come superato. I valori validi includono i numeri decimali. Ad esempio, `50`, `60.5`. I criteri di copertura delle filiali vengono applicati solo ai report sulla copertura del codice. Per ulteriori informazioni sui rapporti sulla copertura del codice, vedere[Report di copertura del codice](test-workflow-actions.md#test-code-coverage-reports).

Interfaccia utente corrispondente:
+ tab/Reports/Automatically discover reports/Success**Criteri di uscita/Copertura delle filiali**
+ **Gli output tab/Reports/Manually configurano i report//Criteri di successo/ Copertura della filiale *report-name-1***

## Vulnerabilities
<a name="github.reports.successcriteria.vulnerabilities"></a>

(*action-name*/Outputs/AutoDiscoverReports/SuccessCriteria/**Vulnerabilities**)

Or

(*action-name*/Outputs/Reports/*report-name-1*/SuccessCriteria/**Vulnerabilities**)

(Facoltativo)

Specificare il numero e la gravità massimi di vulnerabilità consentiti nel rapporto SCA affinché il rapporto associato venga contrassegnato come superato. CodeCatalyst Per specificare le vulnerabilità, è necessario specificare:
+ La gravità minima delle vulnerabilità da includere nel conteggio. I valori validi, dal più grave al meno grave, sono:`CRITICAL`,`HIGH`,, `MEDIUM``LOW`,`INFORMATIONAL`.

  Ad esempio, se si sceglie`HIGH`, verranno `HIGH` `CRITICAL` conteggiate tutte le vulnerabilità.
+ Il numero massimo di vulnerabilità della gravità specificata che desideri consentire. Il superamento di questo numero fa sì che il CodeCatalyst rapporto venga contrassegnato come fallito. I valori validi sono numeri interi.

I criteri di vulnerabilità vengono applicati solo ai report SCA. Per ulteriori informazioni sui report SCA, vedere. [Rapporti di analisi della composizione del software](test-workflow-actions.md#test-sca-reports)

Per specificare la severità minima, utilizzare la `Severity` proprietà. Per specificare il numero massimo di vulnerabilità, utilizzare la `Number` proprietà.

Per ulteriori informazioni sui report SCA, vedere. [Tipi di report sulla qualità](test-workflow-actions.md#test-reporting)

Interfaccia utente corrispondente:
+ tab/Reports/Automatically discover reports/Success**Criteri di uscita/vulnerabilità**
+ **Gli output configurano i report/ /Criteri di successo/ tab/Reports/Manually Vulnerabilità *report-name-1***

## Reports
<a name="github.configuration.reports"></a>

(*action-name*/Outputs/**Reports** )

(Facoltativo)

Una sezione che specifica la configurazione per i report di test.

**Interfaccia utente corrispondente: scheda Output/Report**

## nome-rapporto-1
<a name="github.configuration.reports.report-name-1"></a>

**(nome-relazione-1) *action-name* /Outputs/Reports/**

(Obbligatorio se incluso) [Reports](#github.configuration.reports)

Il nome che vuoi dare al CodeCatalyst rapporto che verrà generato dai tuoi report non elaborati.

**Interfaccia utente corrispondente: Outputs tab/Reports/Manually configura report/nome del report**

## Format
<a name="github.configuration.reports.name.testresults.format"></a>

(*action-name*/Outputs/Reports/*report-name-1*/**Format**)

(Obbligatorio se incluso[Reports](#github.configuration.reports))

Specificate il formato di file che state utilizzando per i report. I valori possibili sono i seguenti.
+ Per i rapporti sui test:
  + Per Cucumber JSON, specifica **Cucumber** (editor visivo) o `CUCUMBERJSON` (editor YAML).
  + Per JUnit XML, specifica **JUnit**(editor visivo) o `JUNITXML` (editor YAML).
  + Per NUnit XML, specificare **NUnit**(editor visuale) o `NUNITXML` (editor YAML).
  + Per NUnit 3 XML, specificare **NUnit3**(editor visuale) o `NUNIT3XML` (editor YAML).
  + Per Visual Studio TRX, specifica **Visual Studio TRX** (editor visivo) o `VISUALSTUDIOTRX` (editor YAML).
  + Per TestNg XML, specificare **TestNg (editor visivo) o `TESTNGXML` (editor YAML**).
+ Per i report sulla copertura del codice:
  + Per Clover XML, specifica **Clover** (editor visivo) o `CLOVERXML` (editor YAML).
  + Per Cobertura XML, specifica **Cobertura** (editor visivo) o (editor YAML). `COBERTURAXML`
  + Per JaCoCo XML, specifica **JaCoCo**(editor visivo) o (editor YAML). `JACOCOXML`
  + Per SimpleCov JSON generato da [simplecov, non da simplecov-json](https://github.com/simplecov-ruby/simplecov)[, specifica Simplecov](https://github.com/vicentllongo/simplecov-json) (editor visivo) o (editor **YAML**). `SIMPLECOV`
+ Per i report di analisi della composizione del software (SCA):
  + Per SARIF, specifica **SARIF** (editor visivo) o `SARIFSCA` (editor YAML).

****Interfaccia utente corrispondente: restituisce il tipo di rapporto e il formato del tab/Reports/Manually configure reports/Add rapporto *report-name-1*****

## Configuration
<a name="github.configuration"></a>

(*action-name*/**Configuration**)

(Obbligatorio) Una sezione in cui è possibile definire le proprietà di configurazione dell'azione. 

Interfaccia utente corrispondente: scheda **Configurazione**

## Steps
<a name="github.configuration.steps"></a>

(*action-name*/Configuration/**Steps**)

(Obbligatorio) 

Specificate il codice GitHub dell'azione così come appare nella pagina dei dettagli dell'azione in [GitHub Marketplace](https://github.com/marketplace). Aggiungi il codice seguendo queste linee guida:

1. Incolla il codice dalla `steps:` sezione GitHub Azione nella `Steps:` sezione del CodeCatalyst flusso di lavoro. Il codice inizia con un trattino (-) e ha un aspetto simile al seguente.

   GitHub codice da incollare:

   ```
   - name: Lint Code Base
     uses: github/super-linter@v4
     env:
       VALIDATE_ALL_CODEBASE: false
       DEFAULT_BRANCH: master
       GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
   ```

1. Rivedi il codice appena incollato e modificalo se necessario in modo che sia conforme agli CodeCatalyst standard. **Ad esempio, con il blocco di codice precedente, è possibile rimuovere il codice e aggiungerlo in *red italics* grassetto.**

   CodeCatalyst flusso di lavoro yaml:

   ```
   Steps:      
      - name: Lint Code Base
        uses: github/super-linter@v4
        env:
          VALIDATE_ALL_CODEBASE: false
          DEFAULT_BRANCH: mastermain
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
   ```

1. Per il codice aggiuntivo incluso nell' GitHub Action ma che non esiste all'interno della `steps:` sezione, aggiungilo al CodeCatalyst flusso di lavoro utilizzando il codice CodeCatalyst -equivalent. Puoi consultarla [Definizione YAML del flusso di lavoro](workflow-reference.md) per avere informazioni dettagliate su come potresti trasferire il tuo GitHub codice. CodeCatalyst Le fasi dettagliate della migrazione non rientrano nell'ambito di questa guida.

Ecco un esempio di come specificare i percorsi dei file in un'azione **GitHub Actions**:

```
Steps:
  - name: Lint Code Base
    uses: github/super-linter@v4
    ...
  - run: cd /sources/WorkflowSource/MyFolder/  && cat file.txt
  - run: cd /artifacts/MyGitHubAction/MyArtifact/MyFolder/  && cat file2.txt
```

Per ulteriori informazioni sulla specificazione dei percorsi dei file, vedere [Riferimento ai file del repository di origine](workflows-sources-reference-files.md) e[Riferimento ai file in un artefatto](workflows-working-artifacts-refer-files.md).

**Interfaccia utente corrispondente: scheda di configurazione/ GitHub Azioni YAML**