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à.
# Integrazione con GitHub Actions
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?
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?
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?
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
+ 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)?
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?
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?
No.
## Immagine di runtime utilizzata dall'GitHub azione «Azioni»
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
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
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
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
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
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
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
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»
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'
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
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
È 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
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
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
(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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
**(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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
(*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
**(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
(*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
(*action-name*/**Configuration**)
(Obbligatorio) Una sezione in cui è possibile definire le proprietà di configurazione dell'azione.
Interfaccia utente corrispondente: scheda **Configurazione**
## Steps
(*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**