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à. # 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\+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": { ... }, "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/ \_Service\_Role. 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)