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à. # CodePipeline riferimento alla struttura della tubazione È possibile CodePipeline utilizzarlo per strutturare una CI/CD pipeline di passaggi automatici che eseguono attività di creazione, test e distribuzione del codice sorgente dell'applicazione. Questa sezione di riferimento fornisce dettagli sulla struttura e i parametri JSON nella pipeline. Per un elenco di alto livello di concetti che descrivono come vengono utilizzate le pipeline, vedi. [CodePipeline concetti ](concepts.md) + Quando crei una pipeline, scegli un'azione sorgente e un provider disponibili, come un bucket S3, un CodeCommit repository, un repository Bitbucket o un GitHub repository che contiene il codice sorgente e avvia la pipeline quando esegui una modifica al codice sorgente. Questa sezione di riferimento fornisce informazioni di riferimento sulle fonti disponibili per la pipeline. Per ulteriori informazioni su come lavorare con le azioni di origine, consulta[Avvia una pipeline in CodePipeline](pipelines-about-starting.md). + Puoi scegliere le azioni e i provider di test, build e deployment che desideri includere automaticamente durante l'esecuzione della pipeline. Questa sezione di riferimento fornisce informazioni di riferimento sulle azioni disponibili e su come si adattano alla pipeline JSON. + La pipeline finita consisterà in una fase di origine e in fasi aggiuntive in cui configurare le azioni per distribuire e testare l'applicazione. Per un esempio concettuale di una DevOps pipeline che distribuisce l'applicazione, consulta. [DevOps esempio di pipeline](concepts-devops-example.md) Per impostazione predefinita, qualsiasi pipeline in cui è stata creata correttamente AWS CodePipeline ha una struttura valida. Tuttavia, se crei o modifichi manualmente un file JSON per creare una pipeline o aggiorni una pipeline da AWS CLI, potresti creare inavvertitamente una struttura non valida. Il seguente riferimento può aiutarti a comprendere meglio i requisiti della struttura della pipeline e la risoluzione dei problemi. Consulta i vincoli in [Quote in AWS CodePipeline](limits.md), che si applicano a tutte le pipeline. Le sezioni seguenti forniscono i parametri di alto livello e la loro posizione nella struttura della pipeline. I requisiti della struttura della tubazione sono dettagliati in ogni sezione per i seguenti tipi di componenti della tubazione: + Riferimento di campo per [Dichiarazione della pipeline](pipeline-requirements.md) + Riferimento di campo per [Dichiarazione di fase](stage-requirements.md) + Riferimento di campo per [Dichiarazione dell'operazione](action-requirements.md) + Elenco [Fornitori di azioni validi in CodePipeline](actions-valid-providers.md) per tipo di azione + Riferimento per [Impostazioni valide per il `PollForSourceChanges` parametro](PollForSourceChanges-defaults.md) + Riferimento per [Artefatti di input e output validi per ogni tipo di azione](reference-action-artifacts.md) + Elenco di collegamenti per [Parametri di configurazione validi per ogni tipo di provider](structure-configuration-examples.md) Per ulteriori informazioni, consulta l'[PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)oggetto nella *Guida CodePipeline API*. L'esempio seguente di visualizzazione della console di pipeline mostra la pipeline denominata new-github, gli stage denominati `Source` e e le azioni provenienti GitHub (tramite GitHub App)`Build`, l'approvazione manuale e i provider di azioni. `manual` CodeBuild ![\[Un esempio della visualizzazione della pipeline nella console. CodePipeline\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/pipeline-console-view.png) La modalità di modifica della pipeline, se visualizzata nel diagramma della console, consente di modificare le sostituzioni delle sorgenti, i trigger e le azioni come illustrato nell'esempio seguente. ![\[Un esempio della modalità di modifica della pipeline nella console. CodePipeline\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/images/pipeline-console-view-edit.png) **Topics** + [Dichiarazione della pipeline](pipeline-requirements.md) + [Dichiarazione di fase](stage-requirements.md) + [Dichiarazione dell'operazione](action-requirements.md) + [Fornitori di azioni validi in CodePipeline](actions-valid-providers.md) + [Impostazioni valide per il `PollForSourceChanges` parametro](PollForSourceChanges-defaults.md) + [Artefatti di input e output validi per ogni tipo di azione](reference-action-artifacts.md) + [Parametri di configurazione validi per ogni tipo di provider](structure-configuration-examples.md) # Dichiarazione della pipeline La pipeline e il livello di metadati di una pipeline hanno una struttura di base che include i parametri e la sintassi seguenti. Il parametro pipeline rappresenta la struttura delle azioni e delle fasi da eseguire nella pipeline. Per ulteriori informazioni, consulta l'[PipelineDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineDeclaration.html)oggetto nella Guida *CodePipeline API*. L'esempio seguente mostra la pipeline e il livello di metadati della struttura della pipeline sia in JSON che in YAML per una pipeline di tipo V2. ------ #### [ YAML ] ``` pipeline: name: MyPipeline roleArn: >- arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline artifactStore: type: S3 location: amzn-s3-demo-bucket stages: ... version: 6 executionMode: SUPERSEDED pipelineType: V2 variables: - name: MyVariable defaultValue: '1' triggers: - providerType: CodeStarSourceConnection gitConfiguration: sourceActionName: Source push: - branches: includes: - main excludes: - feature-branch pullRequest: - events: - CLOSED branches: includes: - main* metadata: pipelineArn: 'arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline' created: '2019-12-12T06:49:02.733000+00:00' updated: '2020-09-10T06:34:07.447000+00:00' pollingDisabledAt: '2020-09-10T06:34:07.447000\$100:00' ``` ------ #### [ JSON ] ``` { "pipeline": { "name": "MyPipeline", "roleArn": "arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline", "artifactStore": { "type": "S3", "location": "amzn-s3-demo-bucket" }, "stages": { ... }, "version": 6, "executionMode": "SUPERSEDED", "pipelineType": "V2", "variables": [ { "name": "MyVariable", "defaultValue": "1" } ], "triggers": [ { "providerType": "CodeStarSourceConnection", "gitConfiguration": { "sourceActionName": "Source", "push": [ { "branches": { "includes": [ "main" ], "excludes": [ "feature-branch" ] } } ], "pullRequest": [ { "events": [ "CLOSED" ], "branches": { "includes": [ "main*" ] } } ] } } ] }, "metadata": { "pipelineArn": "arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline", "created": "2019-12-12T06:49:02.733000+00:00", "updated": "2020-09-10T06:34:07.447000+00:00", "pollingDisabledAt": "2020-09-10T06:34:07.447000+00:00" } } ``` ------ ## `name` Il nome della pipeline. Quando modifichi o aggiorni una pipeline, il nome della pipeline non può essere modificato. **Nota** Se vuoi rinominare una pipeline esistente, puoi utilizzare il comando `get-pipeline` dell'interfaccia a riga di comando per creare un file JSON che contiene la struttura della pipeline. Quindi puoi utilizzare il comando `create-pipeline` dell'interfaccia a riga di comando per creare una pipeline con quella struttura e assegnarle un nuovo nome. ## `roleArn` L'ARN IAM per il ruolo di CodePipeline servizio, ad esempio arn:aws:iam: :80398Example:Role/ \$1Service\$1Role. CodePipeline **Per utilizzare la console per visualizzare l'ARN del ruolo del servizio di pipeline anziché la struttura JSON, scegli la pipeline nella console, quindi scegli Impostazioni.** Nella scheda **Generale**, viene visualizzato il campo **ARN del ruolo di servizio**. ## `artifactStore`OPPURE `artifactStores` Il `artifactStore` campo contiene il tipo e la posizione del bucket di artefatti per una pipeline con tutte le azioni nella stessa regione. AWS Se aggiungi azioni in una regione diversa dalla pipeline, la `artifactStores` mappatura viene utilizzata per elencare il bucket di artefatti per ogni regione in cui vengono eseguite le azioni. AWS Quando crei o modifichi una pipeline, devi disporre di un bucket di artefatti nella regione della pipeline e di un bucket di artefatti per ogni regione in cui prevedi di eseguire un'operazione. **Nota** Nella struttura della pipeline, è necessario includere una delle due `artifactStore` o `artifactStores` nella pipeline, ma non è possibile utilizzarle entrambe. Se crei un'operazione tra Regioni nella pipeline, devi utilizzare `artifactStores`. L'esempio seguente mostra la struttura di base per una pipeline con operazioni tra più regioni che usa il parametro `artifactStores`: ``` "pipeline": { "name": "YourPipelineName", "roleArn": "CodePipeline_Service_Role", "artifactStores": { "us-east-1": { "type": "S3", "location": "S3 artifact bucket name, such as amzn-s3-demo-bucket" }, "us-west-2": { "type": "S3", "location": "S3 artifact bucket name, such as amzn-s3-demo-bucket" } }, "stages": [ { ... ``` ### `type` Il tipo di posizione per il bucket di artefatti, specificato come Amazon S3. ### `location` Il nome del bucket Amazon S3 generato automaticamente la prima volta che crei una pipeline utilizzando la console, ad esempio codepipeline-us-east -2-1234567890, o qualsiasi bucket Amazon S3 fornito per questo scopo ## `stages` Questo parametro contiene il nome di ogni fase della pipeline. *Per ulteriori informazioni sui parametri e sulla sintassi a livello di fase della struttura della pipeline, consultate l'[StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)oggetto nella Guida API. CodePipeline * La struttura della pipeline per le fasi presenta i seguenti requisiti: + Una pipeline deve contenere almeno due fasi. + La prima fase di una pipeline deve contenere almeno un'operazione di origine. Può contenere solo operazioni di origine. + Solo la prima fase di una pipeline può contenere operazioni di origine. + Almeno una fase in ogni pipeline deve contenere un'operazione diversa da un'operazione di origine. + Tutti i nomi delle fasi all'interno di una pipeline devono essere univoci. + I nomi delle fasi non possono essere modificati nella CodePipeline console. Se modificate il nome di uno stadio utilizzando il AWS CLI e lo stage contiene un'azione con uno o più parametri segreti (ad esempio un OAuth token), il valore di tali parametri segreti non viene mantenuto. Dovrai immettere manualmente i valori dei parametri (mascherati da quattro asterischi nel JSON restituito da AWS CLI) e includerli nella struttura JSON. **Importante** Le pipeline che rimangono inattive per più di 30 giorni avranno il polling disabilitato per la pipeline. Per ulteriori informazioni, consulta il riferimento alla struttura della [pollingDisabledAt](#metadata.pollingDisabledAt)pipeline. [Per i passaggi per migrare la pipeline dal polling al rilevamento delle modifiche basato sugli eventi, consulta Metodi di rilevamento delle modifiche.](change-detection-methods.md) ## `version` Il numero di versione di una pipeline viene generato automaticamente e cambia ogni volta che si aggiorna la pipeline. ## `executionMode` È possibile impostare la modalità di esecuzione della pipeline in modo da specificare il comportamento della pipeline per esecuzioni consecutive, come l'accodamento, la sostituzione o l'esecuzione in modalità parallela. Per ulteriori informazioni, consulta [Impostare o modificare la modalità di esecuzione della pipeline](execution-modes.md). **Importante** Per le pipeline in modalità PARALLEL, lo stage rollback non è disponibile. Analogamente, le condizioni di errore con un tipo di risultato di rollback non possono essere aggiunte a una pipeline in modalità PARALLEL. ## `pipelineType` Il tipo di tubazione specifica la struttura e le funzionalità disponibili nella pipeline, ad esempio per una tubazione di tipo V2. Per ulteriori informazioni, consulta [Tipi di tubazioni](pipeline-types.md). ## `variables` Le variabili a livello di tubazione vengono definite al momento della creazione della tubazione e risolte in fase di esecuzione della tubazione. Per ulteriori informazioni, consulta [Riferimento alle variabili](reference-variables.md). Per un tutorial con una variabile a livello di pipeline che viene passata al momento dell'esecuzione della pipeline, vedi. [Tutorial: utilizzare le variabili a livello di pipeline](tutorials-pipeline-variables.md) ## `triggers` I trigger consentono di configurare la pipeline in modo che inizi in base a un particolare tipo di evento o a un tipo di evento filtrato, ad esempio quando viene rilevata una modifica su un particolare ramo o richiesta pull. I trigger sono configurabili per le azioni di origine con connessioni che utilizzano l'`CodeStarSourceConnection`azione in CodePipeline, ad esempio Bitbucket e GitHub. GitLab Per ulteriori informazioni sulle azioni di origine che utilizzano connessioni, consulta. [Aggiungi fornitori di sorgenti di terze parti alle pipeline utilizzando CodeConnections](pipelines-connections.md) Per ulteriori informazioni ed esempi più dettagliati, vedere[Automatizza l'avvio delle pipeline utilizzando trigger e filtri](pipelines-triggers.md). Per il filtraggio, i modelli di espressioni regolari in formato glob sono supportati come descritto in. [Lavorare con i modelli a globo nella sintassi](syntax-glob.md) **Nota** Le azioni di origine di S3 CodeCommit e S3 richiedono una risorsa configurata per il rilevamento delle modifiche (una EventBridge regola) o utilizzano l'opzione per eseguire il polling del repository alla ricerca di modifiche all'origine. Per le pipeline con un'azione di origine Bitbucket o GitHub Enterprise Server GitHub, non è necessario configurare un webhook o impostare il polling come impostazione predefinita. L'azione connessioni gestisce automaticamente il rilevamento delle modifiche. **Importante** Le pipeline che rimangono inattive per più di 30 giorni avranno il polling disabilitato per la pipeline. Per ulteriori informazioni, consulta il riferimento alla struttura della [pollingDisabledAt](#metadata.pollingDisabledAt)pipeline. [Per i passaggi per migrare la pipeline dal polling al rilevamento delle modifiche basato sugli eventi, consulta Metodi di rilevamento delle modifiche.](change-detection-methods.md) ### `gitConfiguration` campi La configurazione Git per il trigger, inclusi i tipi di evento e tutti i parametri per il filtraggio per rami, percorsi di file, tag o eventi di pull request. I campi nella struttura JSON sono definiti come segue: + `sourceActionName`: il nome dell'azione di origine della pipeline con la configurazione Git. + `push`: eventi push con filtro. Questi eventi utilizzano un'operazione OR tra diversi filtri push e un'operazione AND all'interno dei filtri. + `branches`: I rami su cui filtrare. I rami utilizzano un'operazione AND tra le inclusioni e le esclusioni. + `includes`: modelli in base ai quali filtrare i rami che verranno inclusi. Include l'uso di un'operazione OR. + `excludes`: modelli in base ai quali filtrare i rami che verranno esclusi. Esclude l'uso di un'operazione OR. + `filePaths`: i nomi dei percorsi dei file in base ai quali filtrare. + `includes`: modelli in base ai quali filtrare i percorsi dei file che verranno inclusi. Include l'uso di un'operazione OR. + `excludes`: modelli in base ai quali filtrare i percorsi di file che verranno esclusi. Esclude l'utilizzo di un'operazione OR. + `tags`: i nomi dei tag in base ai quali filtrare. + `includes`: modelli in base ai quali filtrare i tag che verranno inclusi. Include l'uso di un'operazione OR. + `excludes`: modelli in base ai quali filtrare i tag che verranno esclusi. Esclude l'uso di un'operazione OR. + `pullRequest`: eventi di pull request con filtraggio sugli eventi di pull request e sui filtri di pull request. + `events`: Filtra sugli eventi di pull request aperti, aggiornati o chiusi come specificato. + `branches`: I rami su cui filtrare. I rami utilizzano un'operazione AND tra le inclusioni e le esclusioni. + `includes`: modelli in base ai quali filtrare i rami che verranno inclusi. Include l'uso di un'operazione OR. + `excludes`: modelli in base ai quali filtrare i rami che verranno esclusi. Esclude l'uso di un'operazione OR. + `filePaths`: i nomi dei percorsi dei file in base ai quali filtrare. + `includes`: modelli in base ai quali filtrare i percorsi dei file che verranno inclusi. Include l'uso di un'operazione OR. + `excludes`: modelli in base ai quali filtrare i percorsi di file che verranno esclusi. Esclude l'utilizzo di un'operazione OR. Di seguito è riportato un esempio della configurazione del trigger per i tipi di eventi di richiesta push e pull. ``` "triggers": [ { "provider": "Connection", "gitConfiguration": { "sourceActionName": "ApplicationSource", "push": [ { "filePaths": { "includes": [ "projectA/**", "common/**/*.js" ], "excludes": [ "**/README.md", "**/LICENSE", "**/CONTRIBUTING.md" ] }, "branches": { "includes": [ "feature/**", "release/**" ], "excludes": [ "mainline" ] }, "tags": { "includes": [ "release-v0", "release-v1" ], "excludes": [ "release-v2" ] } } ], "pullRequest": [ { "events": [ "CLOSED" ], "branches": { "includes": [ "feature/**", "release/**" ], "excludes": [ "mainline" ] }, "filePaths": { "includes": [ "projectA/**", "common/**/*.js" ], "excludes": [ "**/README.md", "**/LICENSE", "**/CONTRIBUTING.md" ] } } ] } } ], ``` ### `push`Campi relativi al tipo di evento per includere ed escludere Il comportamento di inclusione ed esclusione per i livelli dei campi di configurazione Git per i tipi di eventi **push** è mostrato nell'elenco seguente: ``` push (OR operation is used between push and pullRequest or multiples) filePaths (AND operation is used between filePaths, branches, and tags) includes (AND operation is used between includes and excludes) **/FILE.md, **/FILE2 (OR operation is used between file path names) excludes (AND operation is used between includes and excludes) **/FILE.md, **/FILE2 (OR operation is used between file path names) branches (AND operation is used between filePaths, branches, and tags) includes (AND operation is used between includes and excludes) BRANCH/**", "BRANCH2/** (OR operation is used between branch names) excludes (AND operation is used between includes and excludes) BRANCH/**", "BRANCH2/** (OR operation is used between branch names) tags (AND operation is used between filePaths, branches, and tags) includes (AND operation is used between includes and excludes) TAG/**", "TAG2/** (OR operation is used between tag names) excludes (AND operation is used between includes and excludes) TAG/**", "TAG2/** (OR operation is used between tag names) ``` ### `pull request`Campi relativi al tipo di evento per includere ed escludere Il comportamento di inclusione ed esclusione per i livelli dei campi di configurazione Git per i tipi di eventi **pull request** è mostrato nell'elenco seguente: ``` pullRequest (OR operation is used between push and pullRequest or multiples) events (AND operation is used between events, filePaths, and branches). Includes/excludes are N/A for pull request events. filePaths (AND operation is used between events, filePaths, and branches) includes (AND operation is used between includes and excludes) **/FILE.md, **/FILE2 (OR operation is used between file path names) excludes (AND operation is used between includes and excludes) **/FILE.md, **/FILE2 (OR operation is used between file path names) branches (AND operation is used between events, filePaths, and branches) includes (AND operation is used between includes and excludes) BRANCH/**", "BRANCH2/** (OR operation is used between branch names) excludes (AND operation is used between includes and excludes) BRANCH/**", "BRANCH2/** (OR operation is used between branch names) ``` ## `metadata` I campi dei metadati della pipeline sono distinti dalla struttura della pipeline e non possono essere modificati. Quando aggiorni una pipeline, la data nel campo dei metadati `updated` viene modificata automaticamente. ### `pipelineArn` L'Amazon Resource Name (ARN) della pipeline. **Per utilizzare la console per visualizzare l'ARN della pipeline anziché la struttura JSON, scegli la pipeline nella console, quindi scegli Impostazioni.** Nella scheda **Generale**, viene visualizzato il campo **Pipeline ARN**. ### `created` La data e l'ora di creazione della pipeline. ### `updated` La data e l'ora dell'ultimo aggiornamento della pipeline. ### `pollingDisabledAt` Data e ora in cui, per una pipeline configurata per il polling per il rilevamento delle modifiche, il polling è stato disabilitato. Le pipeline che rimangono inattive per più di 30 giorni avranno il polling disabilitato per la pipeline. + Le pipeline inattive disattiveranno il polling dopo 30 giorni di mancata esecuzione. + Le pipeline che utilizzano EventBridge, CodeStar Connections o webhook non saranno influenzate. + Le pipeline attive non saranno interessate. Per ulteriori informazioni, consulta il `pollingDisabledAt` parametro sotto [PipelineMetadata](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PipelineMetadata.html)object nella *Guida CodePipeline API*. [Per i passaggi per migrare la pipeline dal polling al rilevamento delle modifiche basato sugli eventi, consulta Change Detection Methods.](change-detection-methods.md) # Dichiarazione di fase Il livello di fase di una pipeline ha una struttura di base che include i parametri e la sintassi seguenti. Per ulteriori informazioni, consultate l'[StageDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_StageDeclaration.html)oggetto nella Guida * CodePipeline API*. L'esempio seguente mostra il livello di fase della struttura della pipeline sia in JSON che in YAML. L'esempio mostra due fasi denominate e. `Source` `Build` L'esempio contiene due condizioni, una per `onSuccess` e una per`beforeEntry`. ------ #### [ YAML ] ``` pipeline: name: MyPipeline roleArn: >- arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline artifactStore: type: S3 location: amzn-s3-demo-bucket stages: - name: Source actions: - name: Source ... - name: Build actions: - name: Build ... onSuccess: conditions: - result: ROLLBACK rules: - name: DeploymentWindowRule ... beforeEntry: conditions: - result: FAIL rules: - name: MyLambdaRule ... version: 6 metadata: pipelineArn: 'arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline' created: '2019-12-12T06:49:02.733000+00:00' updated: '2020-09-10T06:34:07.447000+00:00' ``` ------ #### [ JSON ] ``` { "pipeline": { "name": "MyPipeline", "roleArn": "arn:aws:iam::ACCOUNT_ID:role/service-role/AWSCodePipelineServiceRole-us-west-2-MyPipeline", "artifactStore": { "type": "S3", "location": "amzn-s3-demo-bucket" }, "stages": [ { "name": "Source", "actions": [ { "name": "Source", ... } ] }, { "name": "Build", "actions": [ { "name": "Build", ... } ], "onSuccess": { "conditions": [ { "result": "ROLLBACK", "rules": [ { "name": "DeploymentWindowRule", ... } ] } ] }, "beforeEntry": { "conditions": [ { "result": "FAIL", "rules": [ { "name": "MyLambdaRule", ... } ] } ] } } ], } ], "version": 6 }, "metadata": { "pipelineArn": "arn:aws:codepipeline:us-west-2:ACCOUNT_ID:MyPipeline", "created": "2019-12-12T06:49:02.733000+00:00", "updated": "2020-09-10T06:34:07.447000+00:00" } } ``` ------ ## `name` Il nome della fase . ## `actions` Il livello di azione di una pipeline ha una struttura di base che include i parametri e la sintassi seguenti. Per visualizzare parametri ed esempi, vedere. [Dichiarazione dell'operazione](action-requirements.md) ## `conditions` Le condizioni contengono una o più regole disponibili in un elenco di regole in CodePipeline. Se tutte le regole di una condizione hanno esito positivo, la condizione viene soddisfatta. È possibile configurare le condizioni in modo che, quando i criteri non vengono soddisfatti, venga attivato il risultato specificato. È possibile configurare i seguenti tipi di condizioni: + `beforeEntry` + `onFailure` + `onSuccess` Per maggiori informazioni ed esempi, consulta [Configurare le condizioni per una fase](stage-conditions.md). ## `rules` Ogni condizione ha un set di regole che è un insieme ordinato di regole che vengono valutate insieme. Pertanto, se una regola non soddisfa la condizione, la condizione fallisce. È possibile sovrascrivere le condizioni delle regole in fase di esecuzione della pipeline. Le regole disponibili sono fornite nel riferimento alle regole. Per ulteriori informazioni, vedere il riferimento alla struttura delle regole all'indirizzo[Riferimento alla struttura delle regole](rule-reference.md). # Dichiarazione dell'operazione Il livello di azione di una pipeline ha una struttura di base che include i parametri e la sintassi seguenti. Per ulteriori informazioni, consultate l'[ActionDeclaration](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_ActionDeclaration.html)oggetto nella Guida *CodePipeline API*. L'esempio seguente mostra il livello di azione della struttura della pipeline sia in JSON che in YAML. ------ #### [ YAML ] ``` . . . stages: - name: Source actions: - name: Source actionTypeId: category: Source owner: AWS provider: S3 version: '1' runOrder: 1 configuration: PollForSourceChanges: 'false' S3Bucket: amzn-s3-demo-bucket S3ObjectKey: codedeploy_linux.zip outputArtifacts: - name: SourceArtifact inputArtifacts: [] region: us-west-2 namespace: SourceVariables - name: Build actions: - name: Build actionTypeId: category: Build owner: AWS provider: CodeBuild version: '1' runOrder: 1 configuration: EnvironmentVariables: >- [{"name":"ETag","value":"#{SourceVariables.ETag}","type":"PLAINTEXT"}] ProjectName: my-project outputArtifacts: - name: BuildArtifact inputArtifacts: - name: SourceArtifact region: us-west-2 namespace: BuildVariables runOrder: 1 configuration: CustomData: >- Here are the exported variables from the build action: S3 ETAG: #{BuildVariables.ETag} outputArtifacts: [] inputArtifacts: [] region: us-west-2 ``` ------ #### [ JSON ] ``` . . . "stages": [ { "name": "Source", "actions": [ { "name": "Source", "actionTypeId": { "category": "Source", "owner": "AWS", "provider": "S3", "version": "1" }, "runOrder": 1, "configuration": { "PollForSourceChanges": "false", "S3Bucket": "amzn-s3-demo-bucket", "S3ObjectKey": "aws-codepipeline-s3-aws-codedeploy_linux.zip" }, "outputArtifacts": [ { "name": "SourceArtifact" } ], "inputArtifacts": [], "region": "us-west-2", "namespace": "SourceVariables" } ] }, { "name": "Build", "actions": [ { "name": "Build", "actionTypeId": { "category": "Build", "owner": "AWS", "provider": "CodeBuild", "version": "1" }, "runOrder": 1, "configuration": { "EnvironmentVariables": "[{\"name\":\"ETag\",\"value\":\"#{SourceVariables.ETag}\",\"type\":\"PLAINTEXT\"}]", "ProjectName": "my-build-project" }, "outputArtifacts": [ { "name": "BuildArtifact" } ], "inputArtifacts": [ { "name": "SourceArtifact" } ], "region": "us-west-2", "namespace": "BuildVariables" } ] . . . ``` ------ Per un elenco di dettagli `configuration` di esempio appropriati per il tipo di provider, consulta [Parametri di configurazione validi per ogni tipo di provider](structure-configuration-examples.md). La struttura dell'operazione ha i seguenti requisiti: + Tutti i nomi delle operazioni all'interno di una fase devono essere univoci. + È richiesta un'azione di origine per ogni pipeline. + Le azioni di origine che non utilizzano una connessione possono essere configurate per il rilevamento delle modifiche o per disattivare il rilevamento delle modifiche. Vedi [Metodi di rilevamento delle modifiche](change-detection-methods.md). + Questo vale per tutte le operazioni, sia che si trovino nella stessa fase o in fasi successive, ma l'artefatto di input non deve essere in stretta sequenza l'azione successiva dell'operazione che ha fornito l'artefatto di output. Le operazioni in parallelo possono dichiarare diversi bundle di artefatti di output che vengono a loro volta usati da diverse operazioni successive. + Quando utilizzi un bucket Amazon S3 come posizione di distribuzione, specifichi anche una chiave di oggetto. Una chiave oggetto può essere un nome di file (oggetto) o una combinazione di un prefisso (percorso di cartella) e nome del file. È possibile utilizzare le variabili per specificare il nome della posizione che la pipeline deve usare. Le operazioni di distribuzione Amazon S3 supportano l'uso delle seguenti variabili nelle chiavi oggetto Amazon S3. **Utilizzo di variabili in Amazon S3** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/action-requirements.html) ## `name` Il nome dell'operazione. ## `region` Per le azioni in cui il provider è un Servizio AWS, il Regione AWS nome della risorsa. Le azioni interregionali utilizzano il `Region` campo per indicare Regione AWS dove devono essere create le azioni. Le AWS risorse create per questa azione devono essere create nella stessa regione fornita nel `region` campo. Non è possibile creare operazioni tra regioni per i seguenti tipi di operazione: + Operazioni di origine + Operazioni da provider di terze parti + Operazioni da provider personalizzati ## `roleArn` L'ARN del ruolo del servizio IAM che esegue l'operazione dichiarata. Ciò viene assunto tramite il RoLearn specificato a livello di pipeline. ## `namespace` Le azioni possono essere configurate con variabili. È possibile utilizzare il campo `namespace` per impostare lo spazio dei nomi e le informazioni variabili per le variabili di esecuzione. Per informazioni di riferimento sulle variabili di esecuzione e sulle variabili di output delle azioni, vedere [Riferimento alle variabili](reference-variables.md). **Nota** Per Amazon ECR, Amazon S3 CodeCommit o sorgenti, puoi anche creare un'override di origine utilizzando input transform entry per utilizzare l' EventBridge in per `revisionValue` il tuo evento pipeline, dove è derivato dalla variabile `revisionValue` dell'evento source per la chiave oggetto, il commit o l'ID immagine. Per ulteriori informazioni, consulta il passaggio facoltativo per l'immissione della trasformazione di input incluso nelle procedure riportate in, o. [Azioni e risorse relative ai sorgenti di Amazon ECR EventBridge](create-cwe-ecr-source.md) [Connessione alle azioni di origine di Amazon S3 con una fonte abilitata per gli eventi](create-S3-source-events.md) [CodeCommit azioni di origine e EventBridge](triggering.md) ## `actionTypeId` L'ID del tipo di azione viene identificato come una combinazione dei seguenti quattro campi. ### `category` Il tipo di azione, o fase, nella pipeline, ad esempio un'azione di origine. Ogni tipo di azione ha un set specifico di provider di azioni validi. Per un elenco di provider validi per tipo di azione, consulta la[Riferimento per la struttura delle operazioni](action-reference.md). Queste sono le `actionTypeId` categorie (tipi di azione) valide per CodePipeline: + `Source` + `Build` + `Approval` + `Deploy` + `Test` + `Invoke` + `Compute` ### `owner` Per tutti i tipi di azione attualmente supportati, l'unica stringa proprietaria valida è `AWS``ThirdParty`, o`Custom`. Per la stringa proprietaria valida per un'azione specifica, vedere[Riferimento per la struttura delle operazioni](action-reference.md). Per ulteriori informazioni, consulta la [documentazione di riferimento dell’API di CodePipeline ](https://docs.aws.amazon.com/codepipeline/latest/APIReference). ### `version` La versione dell'azione. ### `provider` Il fornitore dell'azione, ad esempio CodeBuild. + I tipi di provider validi per una categoria di azioni dipendono dalla categoria. Ad esempio, per una categoria di azioni di origine, un tipo di provider valido è `S3``CodeStarSourceConnection`,`CodeCommit`, o`Amazon ECR`. Questo esempio illustra la struttura per un'operazione di origine con un provider `S3`: ``` "actionTypeId": { "category": "Source", "owner": "AWS", "version": "1", "provider": "S3"}, ``` ## `InputArtifacts` Questo campo contiene la struttura degli artefatti di input, se supportata per la categoria di azioni. L'artefatto di input di un'azione deve corrispondere esattamente all'artefatto di output dichiarato in un'azione precedente. Ad esempio, se un'operazione precedente include la seguente dichiarazione: ``` "outputArtifacts": [ { "MyApp" } ], ``` e non ci sono altri artefatti di output, l'artefatto di input di un'azione successiva deve essere: ``` "inputArtifacts": [ { "MyApp" } ], ``` Ad esempio, un'azione di origine non può avere artefatti di input perché è la prima azione nella pipeline. Tuttavia, un'azione di origine avrà sempre artefatti di output che vengono elaborati dall'azione seguente. Gli artefatti di output per un'azione di origine sono i file dell'applicazione presenti nel repository di origine, compressi e forniti tramite il bucket di artifact, che vengono elaborati mediante la seguente azione, ad esempio un'azione che agisce sui file dell'applicazione con i CodeBuild comandi build. Come esempio di azioni che non possono avere artefatti di output, le azioni di distribuzione non hanno artefatti di output perché queste azioni sono generalmente l'ultima azione in una pipeline. ### `name` Il nome dell'artefatto per gli artefatti di input dell'azione. ## `outputArtifacts` I nomi degli artefatti di output devono essere univoci in una pipeline. Ad esempio, una pipeline può includere un'operazione che ha un artefatto di output denominato `"MyApp"` e un'altra operazione che ha un artefatto di output denominato `"MyBuiltApp"`. Una pipeline invece non può includere due operazioni che hanno entrambe un artefatto di output denominato `"MyApp"`. Questo campo contiene la struttura degli artefatti di output, se supportata per la categoria di azioni. L'artefatto di output di un'azione deve corrispondere esattamente all'artefatto di output dichiarato in un'azione precedente. Ad esempio, se un'operazione precedente include la seguente dichiarazione: ``` "outputArtifacts": [ { "MyApp" } ], ``` e non ci sono altri artefatti di output, l'artefatto di input di un'azione successiva deve essere: ``` "inputArtifacts": [ { "MyApp" } ], ``` Ad esempio, un'azione di origine non può avere artefatti di input perché è la prima azione nella pipeline. Tuttavia, un'azione di origine avrà sempre artefatti di output che vengono elaborati dall'azione seguente. Gli artefatti di output per un'azione di origine sono i file dell'applicazione presenti nel repository di origine, compressi e forniti tramite il bucket di artifact, che vengono elaborati mediante la seguente azione, ad esempio un'azione che agisce sui file dell'applicazione con i CodeBuild comandi build. Come esempio di azioni che non possono avere artefatti di output, le azioni di distribuzione non hanno artefatti di output perché queste azioni sono generalmente l'ultima azione in una pipeline. ### `name` Il nome dell'artefatto per gli artefatti di output dell'azione. ## `configuration`(per fornitore di azioni) La configurazione dell'azione contiene dettagli e parametri appropriati al tipo di provider. Nella sezione seguente, i parametri di configurazione dell'azione di esempio sono specifici dell'azione di origine S3. La configurazione dell'azione e i limiti degli input/output artefatti possono variare in base al provider dell'azione. Per un elenco di esempi di configurazione delle azioni suddivisi per provider di azioni, consulta [Riferimento per la struttura delle operazioni](action-reference.md) e la tabella in essa contenuta. [Parametri di configurazione validi per ogni tipo di provider](structure-configuration-examples.md) La tabella fornisce un collegamento al riferimento all'azione per ogni tipo di provider, che elenca in dettaglio i parametri di configurazione per ogni azione. Per una tabella con i limiti degli artefatti di input e output per ogni provider di azioni, vedere. [Artefatti di input e output validi per ogni tipo di azione](reference-action-artifacts.md) Le seguenti considerazioni si applicano all'utilizzo delle azioni: + Le azioni di origine non hanno artefatti di input e le azioni di distribuzione non hanno artefatti di output. + Per i provider di azioni di origine che non utilizzano una connessione, come S3, è necessario utilizzare il `PollForSourceChanges` parametro per specificare se si desidera che la pipeline si avvii automaticamente quando viene rilevata una modifica. Per informazioni, consulta [Impostazioni valide per il `PollForSourceChanges` parametro](PollForSourceChanges-defaults.md). + Per configurare il rilevamento automatico delle modifiche per avviare la pipeline o per disabilitare il rilevamento delle modifiche, consulta. [Azioni all'origine e metodi di rilevamento delle modifiche](change-detection-methods.md) + Per configurare i trigger con il filtraggio, usa l'azione source per le connessioni, quindi vedi. [Automatizza l'avvio delle pipeline utilizzando trigger e filtri](pipelines-triggers.md) + Per le variabili di output per ogni azione, vedere. [Riferimento alle variabili](reference-variables.md) **Nota** Per Amazon ECR, Amazon S3 CodeCommit o sorgenti, puoi anche creare un'override di origine utilizzando input transform entry per utilizzare l' EventBridge in per `revisionValue` il tuo evento pipeline, dove è derivato dalla variabile `revisionValue` dell'evento source per la chiave oggetto, il commit o l'ID immagine. Per ulteriori informazioni, consulta il passaggio facoltativo per l'immissione della trasformazione di input incluso nelle procedure riportate in, o. [Azioni e risorse relative ai sorgenti di Amazon ECR EventBridge](create-cwe-ecr-source.md) [Connessione alle azioni di origine di Amazon S3 con una fonte abilitata per gli eventi](create-S3-source-events.md) [CodeCommit azioni di origine e EventBridge](triggering.md) **Importante** Alle pipeline che rimangono inattive per più di 30 giorni verrà disattivato il polling relativo alla pipeline. Per ulteriori informazioni, consulta il riferimento alla struttura della [pollingDisabledAt](pipeline-requirements.md#metadata.pollingDisabledAt)pipeline. [Per i passaggi per migrare la pipeline dal polling al rilevamento delle modifiche basato sugli eventi, consulta Metodi di rilevamento delle modifiche.](change-detection-methods.md) **Nota** Le azioni di origine di S3 CodeCommit e S3 richiedono una risorsa di rilevamento delle modifiche configurata (una EventBridge regola) o utilizzano l'opzione per eseguire il polling del repository alla ricerca di modifiche all'origine. Per le pipeline con un'azione di origine Bitbucket o GitHub Enterprise Server GitHub, non è necessario configurare un webhook o impostare il polling come impostazione predefinita. L'azione connessioni gestisce automaticamente il rilevamento delle modifiche. ## `runOrder` Un numero intero positivo che indica l'ordine di esecuzione dell'azione all'interno dello stadio. Le azioni parallele nella fase vengono visualizzate come aventi lo stesso numero intero. Ad esempio, due azioni con un ordine di esecuzione pari a due verranno eseguite in parallelo dopo l'esecuzione della prima azione nello stage. Il valore predefinito di `runOrder` per un'operazione è 1. Il valore deve essere un numero intero positivo (numero naturale). Non puoi utilizzare frazioni, decimali, numeri negativi o zero. Per specificare una sequenza di operazioni in serie, utilizza il numero più piccolo per la prima operazione e i numeri più grandi per ciascuna delle restanti operazioni della sequenza. Per specificare operazioni parallele, usa lo stesso numero intero per ciascuna operazione che vuoi eseguire in parallelo. Nella console, puoi specificare una sequenza seriale per un'azione scegliendo **Aggiungi gruppo di azioni** al livello della fase in cui desideri che venga eseguita oppure puoi specificare una sequenza parallela scegliendo **Aggiungi azione**. *Il gruppo di azioni* si riferisce a un ordine di esecuzione di una o più azioni allo stesso livello. Ad esempio, se vuoi eseguire tre azioni in sequenza in una fase, darai alla prima operazione il valore di `runOrder` 1, alla seconda operazione il valore di `runOrder` 2 e alla terza il valore di `runOrder` 3. Tuttavia, se vuoi che la seconda e la terza operazione vengano eseguite in parallelo, darai alla prima operazione il valore di `runOrder` 1 e alla seconda e alla terza operazione il valore di `runOrder` 2. **Nota** La numerazione delle operazioni in serie non deve essere rigorosamente in sequenza. Ad esempio, se hai tre operazioni in una sequenza e decidi di rimuovere la seconda operazione, non è necessario rinumerare il valore di `runOrder` della terza operazione. Infatti, poiché il valore di `runOrder` di quell'operazione (3) è superiore al valore di `runOrder` della prima operazione (1), viene comunque eseguita in serie dopo la prima operazione della fase. # Fornitori di azioni validi in CodePipeline Il formato della struttura della pipeline viene utilizzato per creare operazioni e fasi in una pipeline. Un tipo di operazione è costituito da una categoria di operazione e un tipo di provider. Ogni categoria di azioni ha un elenco valido di fornitori di azioni. Per fare riferimento ai provider di azioni validi per ogni categoria di azioni, consulta la[Riferimento per la struttura delle operazioni](action-reference.md). Ogni categoria di operazione dispone di una serie definita di provider. Ogni provider di azioni, ad esempio Amazon S3, ha un nome di provider, ad esempio`S3`, che deve essere utilizzato nel `Provider` campo della categoria di azioni nella struttura della pipeline. Esistono tre valori validi per il campo `Owner` nella sezione categoria di azioni nella struttura della pipeline: `AWS`, `ThirdParty` e `Custom`. Per trovare il nome del provider e le informazioni sul proprietario del tuo action provider, consulta o. [Riferimento per la struttura delle operazioni](action-reference.md) [Artefatti di input e output validi per ogni tipo di azione](reference-action-artifacts.md) La seguente tabella elenca i provider validi per tipo di operazione. **Nota** Per le azioni di Bitbucket o GitHub Enterprise Server, consulta l'argomento di riferimento sull'[CodeStarSourceConnection per Bitbucket Cloud, GitHub Enterprise Server GitHub, GitLab .com e GitLab azioni autogestite](action-reference-CodestarConnectionSource.md)azione. GitHub **Provider validi per tipo di operazione** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/actions-valid-providers.html) Alcuni tipi di azione CodePipeline sono disponibili solo in alcune AWS regioni. È possibile che un tipo di azione sia disponibile in una AWS regione, ma non è disponibile un AWS provider per quel tipo di azione. Per ulteriori informazioni su ogni provider di operazione, consulta [Integrazioni con tipi di CodePipeline azioni](integrations-action-type.md). # Impostazioni valide per il `PollForSourceChanges` parametro Il valore predefinito del parametro `PollForSourceChanges` è determinato dal metodo utilizzato per creare la pipeline, come decritto nella seguente tabella. In molti casi, il parametro `PollForSourceChanges` è preimpostato su "true" e deve essere disabilitato. Quando il parametro `PollForSourceChanges` è preimpostato su "true", devi eseguire le operazioni seguenti: + Aggiungere il parametro `PollForSourceChanges` al file JSON o al modello CloudFormation . + Crea risorse per il rilevamento delle modifiche (regola CloudWatch Eventi, se applicabile). + Imposta il parametro `PollForSourceChanges` su false. **Nota** Se si crea una regola CloudWatch Events o un webhook, è necessario impostare il parametro su false per evitare di attivare la pipeline più di una volta. Il `PollForSourceChanges` parametro non viene utilizzato per le azioni di origine di Amazon ECR. + **`PollForSourceChanges`parametri predefiniti** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/PollForSourceChanges-defaults.html) # Artefatti di input e output validi per ogni tipo di azione A seconda del tipo di azione e del provider, è possibile avere il seguente numero di artefatti di input e output. **Vincoli del tipo di operazione per gli artefatti** | Owner | Tipo di operazione | Provider | Numero di artefatti di input validi | Numero di artefatti di output validi | | --- | --- | --- | --- | --- | | AWS | Origine | S3 | 0 | 1 | | AWS | Origine | CodeCommit | 0 | 1 | | AWS | Origine | ECR | 0 | 1 | | ThirdParty | Origine | CodeStarSourceConnection | 0 | 1 | | AWS | Creazione | CodeBuild | Da 1 a 5 | Da 0 a 5 | | AWS | Test | CodeBuild | Da 1 a 5 | Da 0 a 5 | | AWS | Test | DeviceFarm | 1 | 0 | | AWS | Approval | ThirdParty | 0 | 0 | | AWS | Implementazione | S3 | 1 | 0 | | AWS | Implementazione | CloudFormation | Da 0 a 10 | Da 0 a 1 | | AWS | Implementazione | CodeDeploy | 1 | 0 | | AWS | Implementazione | ElasticBeanstalk | 1 | 0 | | AWS | Implementazione | OpsWorks | 1 | 0 | | AWS | Implementazione | ECS | 1 | 0 | | AWS | Implementazione | ServiceCatalog | 1 | 0 | | AWS | Invoke | Lambda | Da 0 a 5 | Da 0 a 5 | | ThirdParty | Implementazione | AlexaSkillsKit | Da 1 a 2 | 0 | | Custom | Creazione | Jenkins | Da 0 a 5 | Da 0 a 5 | | Custom | Test | Jenkins | Da 0 a 5 | Da 0 a 5 | | Custom | Qualsiasi categoria supportata | Come specificato nell'operazione personalizzata | Da 0 a 5 | Da 0 a 5 | # Parametri di configurazione validi per ogni tipo di provider Questa sezione elenca i parametri `configuration` validi per ogni provider di operazione. Ogni operazione deve avere una configurazione valida che dipende dal tipo di provider dell'operazione stessa. Nella seguente tabella sono elencati gli elementi di configurazione dell'operazione richiesti per ogni tipo di provider valido: **Proprietà di configurazione dell'operazione per i tipi di provider** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/codepipeline/latest/userguide/structure-configuration-examples.html) L'esempio seguente mostra la configurazione valida per un'operazione di distribuzione che utilizza Alexa Skills Kit: ``` "configuration": { "ClientId": "amzn1.application-oa2-client.aadEXAMPLE", "ClientSecret": "****", "RefreshToken": "****", "SkillId": "amzn1.ask.skill.22649d8f-0451-4b4b-9ed9-bfb6cEXAMPLE" } ``` L'esempio seguente mostra una configurazione valida per un'approvazione manuale: ``` "configuration": { "CustomData": "Comments on the manual approval", "ExternalEntityLink": "http://my-url.com", "NotificationArn": "arn:aws:sns:us-west-2:12345EXAMPLE:Notification" } ```