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à.
Riferimento alle specifiche di costruzione per CodeBuild
Questo argomento fornisce importanti informazioni di riferimento sui file di specifiche di compilazione (buildspec). Un buildspec è una raccolta di comandi di compilazione e impostazioni correlate, in formato YAML, che viene CodeBuild utilizzata per eseguire una build. Puoi includere un buildspec come parte del codice sorgente oppure puoi definire un buildspec quando crei un progetto di build. Per informazioni sul funzionamento di una specifica di build, consulta Come CodeBuild funziona.
Argomenti
Nome del file buildspec e posizione di storage
Se includi una buildspec come parte del codice sorgente, per impostazione predefinita il file deve essere denominato buildspec.yml e deve trovarsi nella root della directory di origine.
È possibile sostituire il nome e la posizione del file buildspec. Ad esempio, puoi:
-
Utilizzare un file buildspec diverso per diverse build nello stesso repository, ad esempio
buildspec_debug.ymlebuildspec_release.yml. -
Archiviare un file buildspec in una posizione diversa rispetto alla root della directory di origine, ad esempio
config/buildspec.ymlo in un bucket S3. Il bucket S3 deve trovarsi nella stessa regione del progetto di build. AWS Specificare il file buildspec utilizzando il relativo ARN (ad esempio,arn:aws:s3:::).<my-codebuild-sample2>/buildspec.yml
Puoi specificare solo una buildspec per ogni progetto di compilazione, indipendentemente dal nome del file buildspec.
Per sostituire il nome o la posizione predefiniti del file buildspec o entrambi, eseguire una delle seguenti operazioni:
-
Esegui il
update-projectcomando AWS CLIcreate-projector, impostando ilbuildspecvalore del percorso del file buildspec alternativo relativo al valore della variabile di ambiente integrata.CODEBUILD_SRC_DIRÈ inoltre possibile eseguire l'equivalente con l'create projectoperazione in. AWS SDKs Per ulteriori informazioni, consulta Creazione di un progetto di compilazione o Modificare le impostazioni del progetto di costruzione. -
Eseguite il AWS CLI
start-buildcomando, impostando ilbuildspecOverridevalore del percorso del file buildspec alternativo relativo al valore della variabile di ambiente incorporata.CODEBUILD_SRC_DIRÈ inoltre possibile eseguire l'equivalente con l'start buildoperazione in. AWS SDKs Per ulteriori informazioni, consulta Esegui le build manualmente. -
In un AWS CloudFormation modello, imposta la
BuildSpecproprietà diSourcein una risorsa di tipoAWS::CodeBuild::Projectsul percorso del file buildspec alternativo relativo al valore della variabile di ambiente incorporata.CODEBUILD_SRC_DIRPer ulteriori informazioni, consultate la BuildSpec proprietà nel codice sorgente del AWS CodeBuild progetto nella Guida per l'utente.AWS CloudFormation
Sintassi buildspec
I file buildspec devono essere espressi in formato YAML
Se un comando contiene un carattere, o una stringa di caratteri, che non è supportato da YAML, è necessario racchiudere il comando tra virgolette (""). Il seguente comando è racchiuso tra virgolette perché un segno di due punti (:) seguito da uno spazio non è consentito in YAML. La virgoletta nel comando è escape (\").
"export PACKAGE_NAME=$(cat package.json | grep name | head -1 | awk -F: '{ print $2 }' | sed 's/[\",]//g')"
Buildspec presenta la seguente sintassi:
version: 0.2 run-as:Linux-user-nameenv: shell:shell-tagvariables:key: "value"key: "value" parameter-store:key: "value"key: "value" exported-variables: -variable-variablesecrets-manager:key:secret-id:json-key:version-stage:version-idgit-credential-helper: no | yes proxy: upload-artifacts: no | yes logs: no | yes batch: fast-fail: false | true # build-list: # build-matrix: # build-graph: # build-fanout: phases: install: run-as:Linux-user-nameon-failure: ABORT | CONTINUE | RETRY | RETRY-count| RETRY-regex| RETRY-count-regexruntime-versions:runtime:versionruntime:versioncommands: -command-commandfinally: -command-commandpre_build: run-as:Linux-user-nameon-failure: ABORT | CONTINUE | RETRY | RETRY-count| RETRY-regex| RETRY-count-regexcommands: -command-commandfinally: -command-commandbuild: run-as:Linux-user-nameon-failure: ABORT | CONTINUE | RETRY | RETRY-count| RETRY-regex| RETRY-count-regexcommands: -command-commandfinally: -command-commandpost_build: run-as:Linux-user-nameon-failure: ABORT | CONTINUE | RETRY | RETRY-count| RETRY-regex| RETRY-count-regexcommands: -command-commandfinally: -command-commandreports:report-group-name-or-arn: files: -location-locationbase-directory:locationdiscard-paths: no | yes file-format:report-formatartifacts: files: -location-locationname:artifact-namediscard-paths: no | yes base-directory:locationexclude-paths:excluded pathsenable-symlinks: no | yes s3-prefix:prefixsecondary-artifacts:artifactIdentifier: files: -location-locationname:secondary-artifact-namediscard-paths: no | yes base-directory:locationartifactIdentifier: files: -location-locationdiscard-paths: no | yes base-directory:locationcache: key:keyfallback-keys: -fallback-key-fallback-keyaction: restore | save paths: -path-path
Il file buildspec contiene quanto segue:
version
Mappatura obbligatoria. Rappresenta la versione buildspec. Ti consigliamo di utilizzare 0.2.
Nota
Anche se la versione 0.1 è ancora supportata, consigliamo di utilizzare la versione 0.2 ogni volta che è possibile. Per ulteriori informazioni, consulta Versioni di buildspec.
run-as
Sequenza opzionale. Disponibile per gli utenti Linux. Speciifica un utente Linux che esegue i comandi in questo file buildspec. run-asconcede all'utente specificato le autorizzazioni di lettura ed esecuzione. Quando specifichi run-as nella parte superiore del file buildspec, viene applicato globalmente a tutti i comandi. Se non vuoi specificare un utente per tutti i comandi del file buildspec, puoi specificarne uno per i comandi di una fase utilizzando run-as in uno dei blocchi phases. Se run-as non è specificato, tutti i comandi vengono eseguiti come utente root.
env
Sequenza opzionale. Rappresenta le informazioni su una o più variabili di ambiente personalizzate.
Nota
Per proteggere le informazioni riservate, nei log sono nascoste le seguenti informazioni: CodeBuild
-
AWS chiave IDs di accesso. Per ulteriori informazioni, consulta Managing Access Keys for IAM Users nella Guida per l'AWS Identity and Access Management utente.
-
Stringhe specificate utilizzando l'archivio parametri. Per ulteriori informazioni, consulta la procedura dettagliata della console di Systems Manager Parameter Store e Systems Manager Parameter Store nella Guida per l'utente di Amazon EC2 Systems Manager.
-
Stringhe specificate utilizzando. AWS Secrets Manager Per ulteriori informazioni, consulta Gestione delle chiavi.
- env/ shell
-
Sequenza opzionale. Speciifica la shell supportata per i sistemi operativi Linux o Windows.
Per i sistemi operativi Linux, i tag shell supportati sono:
-
bash -
/bin/sh
Per i sistemi operativi Windows, i tag shell supportati sono:
-
powershell.exe -
cmd.exe
-
- env/variables
-
Obbligatorio se è specificato
enve si desidera definire variabili di ambiente personalizzate in testo normale. Contiene una mappatura dikey/valuescalari, in cui ogni mappatura rappresenta una singola variabile di ambiente personalizzata in testo semplice.keyè il nome della variabile di ambiente personalizzata edvalueè il valore di quella variabile.Importante
Sconsigliamo vivamente la memorizzazione di valori sensibili nelle variabili di ambiente. Le variabili di ambiente possono essere visualizzate in testo semplice utilizzando strumenti come la CodeBuild console e il AWS CLI. Per i valori sensibili, consigliamo di utilizzare la mappatura
parameter-storeosecrets-manager, come descritto più avanti in questa sezione.Tutte le variabili di ambiente impostate sostituiscono quelle esistenti. Ad esempio, se l'immagine Docker contiene già una variabile di ambiente denominata
MY_VARcon un valore dimy_value, e si imposta una variabile di ambiente denominataMY_VARcon un valore diother_value, il valoremy_valueviene sostituito daother_value. Allo stesso modo, se l'immagine Docker contiene già una variabile di ambiente denominataPATHcon un valore di/usr/local/sbin:/usr/local/bin, e si imposta una variabile di ambiente denominataPATHcon un valore di$PATH:/usr/share/ant/bin, il valore di/usr/local/sbin:/usr/local/binviene sostituito dal valore letterale$PATH:/usr/share/ant/bin.Non impostare variabili di ambiente con nomi che iniziano con
CODEBUILD_. Questo prefisso è riservato per l'uso interno .Se una variabile di ambiente con lo stesso nome viene definita in più luoghi, il valore viene determinato come segue:
-
Il valore della chiamata all'operazione di inizio della compilazione ha la massima priorità. Al momento della creazione di una compilazione è possibile aggiungere o sostituire variabili di ambiente. Per ulteriori informazioni, consulta Esegui AWS CodeBuild le build manualmente.
-
Il valore della definizione del progetto di compilazione è il seguente in ordine di priorità. Quando crei o modifichi un progetto, puoi aggiungere variabili di ambiente a livello di progetto. Per ulteriori informazioni, consultare Crea un progetto di compilazione in AWS CodeBuild e Modifica le impostazioni del progetto di compilazione in AWS CodeBuild.
-
Il valore della dichiarazione buildspec ha la minima priorità.
-
- env/parameter-store
-
Obbligatorio se
envè specificato e desideri recuperare variabili di ambiente personalizzate archiviate in Amazon EC2 Systems Manager Parameter Store. Contiene una mappatura dikey/valuescalars, in cui ogni mappatura rappresenta una singola variabile di ambiente personalizzata memorizzata in Amazon EC2 Systems Manager Parameter Store.keyè il nome che usi più avanti nei comandi di compilazione per fare riferimento a questa variabile di ambiente personalizzata edvalueè il nome della variabile di ambiente personalizzata memorizzata in Amazon EC2 Systems Manager Parameter Store. Per memorizzare valori sensibili, consulta Systems Manager Parameter Store and Walkthrough: Create and test a String parameter (console) nella Amazon EC2 Systems Manager User Guide.Importante
CodeBuild Per consentire il recupero di variabili di ambiente personalizzate archiviate in Amazon EC2 Systems Manager Parameter Store, devi aggiungere l'
ssm:GetParametersazione al tuo ruolo CodeBuild di servizio. Per ulteriori informazioni, consulta Consenti CodeBuild di interagire con altri servizi AWS.Tutte le variabili di ambiente recuperate da Amazon EC2 Systems Manager Parameter Store sostituiscono le variabili di ambiente esistenti. Ad esempio, se l'immagine Docker contiene già una variabile di ambiente denominata
MY_VARcon un valore dimy_valuee si recupera una variabile di ambiente denominataMY_VARcon un valore diother_value, il valoremy_valueviene sostituito daother_value. Allo stesso modo, se l'immagine Docker contiene già una variabile di ambiente denominataPATHcon un valore di/usr/local/sbin:/usr/local/bine si recupera una variabile di ambiente denominataPATHcon un valore di$PATH:/usr/share/ant/bin, il valore di/usr/local/sbin:/usr/local/binviene sostituito dal valore letterale$PATH:/usr/share/ant/bin.Non archiviare variabili di ambiente con nomi che iniziano con
CODEBUILD_. Questo prefisso è riservato per l'uso interno .Se una variabile di ambiente con lo stesso nome viene definita in più luoghi, il valore viene determinato come segue:
-
Il valore della chiamata all'operazione di inizio della compilazione ha la massima priorità. Al momento della creazione di una compilazione è possibile aggiungere o sostituire variabili di ambiente. Per ulteriori informazioni, consulta Esegui AWS CodeBuild le build manualmente.
-
Il valore della definizione del progetto di compilazione è il seguente in ordine di priorità. Quando crei o modifichi un progetto, puoi aggiungere variabili di ambiente a livello di progetto. Per ulteriori informazioni, consultare Crea un progetto di compilazione in AWS CodeBuild e Modifica le impostazioni del progetto di compilazione in AWS CodeBuild.
-
Il valore della dichiarazione buildspec ha la minima priorità.
-
- env/secrets-manager
-
Obbligatorio se desideri recuperare variabili di ambiente personalizzate memorizzate in. AWS Secrets Manager Specificate un Secrets Manager
reference-keyutilizzando il seguente schema::<key><secret-id>:<json-key>:<version-stage>:<version-id><key>-
(Obbligatorio) Il nome della variabile di ambiente locale. Usa questo nome per accedere alla variabile durante la compilazione.
<secret-id>-
(Obbligatorio) Il nome o Amazon Resource Name (ARN) che funge da identificatore univoco per il segreto. Per accedere a un segreto nel tuo account AWS , devi semplicemente specificare il nome segreto. Per accedere a un segreto in un altro AWS account, specifica l'ARN segreto.
<json-key>-
(Facoltativo) Specificate il nome della chiave della coppia chiave-valore di Secrets Manager di cui desiderate recuperare il valore. Se non si specifica a
json-key, CodeBuild recupera l'intero testo segreto. <version-stage>-
(Facoltativo) Specificate la versione segreta che desiderate recuperare tramite l'etichetta temporanea allegata alla versione. Le etichette temporanee sono utilizzate per tenere traccia di differenti versioni durante il processo di rotazione. Se utilizzi
version-stage, non specificareversion-id. Se non specifichi una fase o un ID di versione, l'impostazione predefinita è recuperare la versione con il valore di fase di versioneAWSCURRENT. <version-id>-
(Facoltativo) Specificate l'identificatore univoco della versione del segreto che desiderate utilizzare. Se specifichi
version-id, non specificareversion-stage. Se non specifichi una fase o un ID di versione, l'impostazione predefinita è recuperare la versione con il valore di fase di versioneAWSCURRENT.
Nell'esempio seguente,
TestSecretè il nome della coppia chiave-valore memorizzata in Secrets Manager. La chiave perTestSecretè.MY_SECRET_VARSi accede alla variabile durante la compilazione utilizzando ilLOCAL_SECRET_VARnome.env: secrets-manager: LOCAL_SECRET_VAR: "TestSecret:MY_SECRET_VAR"Per ulteriori informazioni, consulta Che cos'è AWS Secrets Manager? nella Guida per l'utente di AWS Secrets Manager .
- env/exported-variables
-
Mappatura opzionale. Utilizzato per elencare le variabili di ambiente che si desidera esportare. Specificare il nome di ogni variabile che si desidera esportare su una riga separata sotto
exported-variables. La variabile che si desidera esportare deve essere disponibile nel contenitore durante la compilazione. La variabile esportata può essere una variabile di ambiente.Le variabili di ambiente esportate vengono utilizzate insieme AWS CodePipeline a per esportare le variabili di ambiente dalla fase di compilazione corrente alle fasi successive della pipeline. Per ulteriori informazioni, consulta Lavorare con le variabili nella Guida per l'AWS CodePipeline utente.
Durante una compilazione, il valore di una variabile è disponibile a partire dalla fase
install. Può essere aggiornato tra l'inizio della faseinstalle la fine della fasepost_build. Al termine della fasepost_build, il valore delle variabili esportate non può cambiare.Nota
Non è possibile esportare quanto segue:
-
I segreti EC2 di Amazon Systems Manager Parameter Store specificati nel progetto di compilazione.
-
Secrets Manager: segreti specificati nel progetto di compilazione
-
Variabili di ambiente che iniziano con
AWS_.
-
- env/ git-credential-helper
-
Mappatura opzionale. Usato per indicare se CodeBuild utilizza il suo helper di credenziali Git per fornire le credenziali Git.
yesse è usato. In caso contrario,noo non specificato. Per ulteriori informazioni, consulta gitcredentialssul sito Web Git. Nota
git-credential-helpernon è supportato per le compilazioni attivate da un webhook per un repository Git pubblico.
proxy
Sequenza opzionale. Utilizzato per rappresentare le impostazioni se esegui la compilazione in un server proxy esplicito. Per ulteriori informazioni, consulta Esegui CodeBuild in un server proxy esplicito.
- proxy/upload-artifacts
-
Mappatura opzionale. Imposta su
yesse desideri che la compilazione in un server proxy esplicito carichi artefatti. Il valore predefinito èno. - proxy/logs
-
Mappatura opzionale. Imposta su
yesper la creazione di un server proxy esplicito per la creazione di CloudWatch registri. Il valore predefinito èno.
phases
Sequenza obbligatoria. Rappresenta i comandi CodeBuild eseguiti durante ogni fase della compilazione.
Nota
Nella versione 0.1 di buildspec, CodeBuild esegue ogni comando in un'istanza separata della shell predefinita nell'ambiente di compilazione. Questo significa che ogni comando viene eseguito separatamente da tutti gli altri comandi. Pertanto, come impostazione predefinita, non è possibile eseguire un singolo comando che si basa sullo stato di qualsiasi comando precedente (per esempio, modificare le directory o impostare le variabili di ambiente). Per aggirare questo limite, suggeriamo di utilizzare la versione 0.2, che risolve questo problema. Se devi utilizzare la versione 0.1 di buildspec, ti consigliamo gli approcci indicati in Shell e comandi negli ambienti di compilazione.
- phases/*/run-as
-
Sequenza opzionale. Viene utilizzato in una fase di compilazione per specificare un utente Linux che esegue i comandi. Se
run-asè specificato anche a livello globale per tutti i comandi nella parte superiore del file buildspec, l'utente a livello di fase ha la priorità. Ad esempio, se globalmenterun-asspecifica User-1 e per la faseinstallsolo una istruzionerun-asspecifica User-2, tutti i comandi nel file buildspec vengono eseguiti come User-1 eccetto i comandi nella faseinstallche vengono eseguiti come User-2. - phases/*/ in caso di errore
-
Sequenza opzionale. Speciifica l'azione da intraprendere se si verifica un errore durante la fase. Può essere uno dei seguenti valori:
-
ABORT- Interrompi la compilazione. -
CONTINUE- Passa alla fase successiva. -
RETRY- Riprova la compilazione fino a 3 volte con un messaggio di errore che corrisponde all'espressione.*regolare. -
RETRY-- Riprova la compilazione per un numero specificato di volte, come rappresentato da un messaggiocountcountdi errore che corrisponde all'espressione regolare..*Nota checountdeve essere compreso tra 0 e 100. Ad esempio, i valori validi includonoRETRY-4eRETRY-8. -
RETRY-- Riprova la compilazione fino a 3 volte e usalaregexregexper includere un'espressione regolare che corrisponda a un messaggio di errore specificato. Ad esempio, i valori validi includonoRetry-.*Error: Unable to connect to database.*e.RETRY-invalid+ -
RETRY-- Riprova la build per un numero di volte specificato, come rappresentato dacount-regexcount. Nota checountdeve essere compreso tra 0 e 100. Puoi anche usareregexper includere un'espressione regolare che corrisponda al messaggio di errore. Ad esempio, i valori validi includonoRetry-3-.*connection timed out.*eRETRY-8-invalid+.
Se questa proprietà non è specificata, il processo di fallimento segue le fasi di transizione illustrate inTransizioni delle fasi della compilazione.
Importante
L'
on-failureattributo non è supportato quando si utilizza l'elaborazione Lambda o la capacità riservata. Questo attributo funziona solo con le immagini di EC2 calcolo fornite da. CodeBuild -
- fasi/*/ finalmente
-
Blocco opzionale. I comandi specificati in un
finallyblocco vengono eseguiti dopo i comandi nel blocco.commandsI comandi in unfinallyblocco vengono eseguiti anche se un comando nelcommandsblocco ha esito negativo. Ad esempio, se ilcommandsblocco contiene tre comandi e il primo ha esito negativo, CodeBuild ignora i due comandi rimanenti ed esegue tutti i comandi delfinallyblocco. La fase va a buon fine quando l'esecuzione di tutti i comandi nei blocchicommandsefinallyvengono completata. Se uno qualunque dei comandi nella fase non va a buon fine, la fase non va a buon fine:
I nomi delle fasi di build ammessi sono:
- phases/install
-
Sequenza opzionale. Rappresenta gli eventuali comandi che vengono CodeBuild eseguiti durante l'installazione. Ti consigliamo di utilizzare la fase
installsolo per installare pacchetti nell'ambiente di build. Ad esempio, è possibile utilizzare questa fase per installare un framework di test del codice come Mocha o RSpec.- phases/install/runtime-versions
-
Sequenza opzionale. Una versione runtime è supportata con l'immagine standard di Ubuntu 5.0 o successiva e l'immagine standard Amazon Linux 2 4.0 o successiva. Se specificata, almeno un runtime deve essere incluso in questa sezione. Specificate un runtime utilizzando una versione specifica, una versione principale seguita
.xda specificare che CodeBuild utilizza quella versione principale con la versione secondaria più recente olatestper utilizzare la versione principale e secondaria più recente (ad esempioruby: 3.2,nodejs: 18.x, ojava: latest). Puoi specificare il runtime utilizzando un numero o una variabile di ambiente. Ad esempio, se utilizzi l'immagine standard di Amazon Linux 2 4.0, quanto segue specifica che è installata la versione 17 di Java, l'ultima versione secondaria di python versione 3 e una versione contenuta in una variabile di ambiente di Ruby. Per ulteriori informazioni, consulta Immagini Docker fornite da CodeBuild.phases: install: runtime-versions: java: corretto8 python: 3.x ruby: "$MY_RUBY_VAR"È possibile specificare uno o più runtime nella sezione
runtime-versionsdel file buildspec. Se il runtime dipende da un altro runtime, è anche possibile specificarne il runtime dipendente nel file buildspec. Se non specifichi alcun runtime nel file buildspec, CodeBuild sceglie i runtime predefiniti disponibili nell'immagine che usi. Se specificate uno o più runtime, utilizza solo tali runtime. CodeBuild Se non viene specificato un runtime dipendente, CodeBuild tenta di scegliere automaticamente il runtime dipendente.Se due runtime specificati sono in conflitto, la compilazione ha esito negativo. Ad esempio,
android: 29ejava: openjdk11sono in conflitto, perciò, se vengono specificati entrambi, la compilazione non riesce.Per ulteriori informazioni sui runtime disponibili, vedereRuntime disponibili.
Nota
Se specifichi una
runtime-versionssezione e usi un'immagine diversa da Ubuntu Standard Image 2.0 o versione successiva o dall'immagine standard Amazon Linux 2 (AL2) 1.0 o successiva, la build emette l'avviso "Skipping install of runtimes. Runtime version selection is not supported by this build image.»
- phases/install/commands
-
Sequenza opzionale. Contiene una sequenza di scalari, in cui ogni scalare rappresenta un singolo comando che CodeBuild viene eseguito durante l'installazione. CodeBuild esegue ogni comando, uno alla volta, nell'ordine elencato, dall'inizio alla fine.
- phases/pre_build
-
Sequenza opzionale. Rappresenta gli eventuali comandi CodeBuild eseguiti prima della compilazione. Ad esempio, potresti utilizzare questa fase per accedere ad Amazon ECR o installare npm dependencies.
- phases/pre_build/commands
-
Sequenza obbligatoria se viene specificato
pre_build. Contiene una sequenza di scalari, in cui ogni scalare rappresenta un singolo comando che CodeBuild viene eseguito prima della compilazione. CodeBuildesegue ogni comando, uno alla volta, nell'ordine elencato, dall'inizio alla fine.
- phases/build
-
Sequenza opzionale. Rappresenta gli eventuali comandi CodeBuild eseguiti durante la compilazione. Ad esempio, è possibile utilizzare questa fase per eseguire Mocha o RSpec sbt.
- phases/build/commands
-
Obbligatorio se
buildspecificato. Contiene una sequenza di scalari, in cui ogni scalare rappresenta un singolo comando che CodeBuild viene eseguito durante la compilazione. CodeBuild esegue ogni comando, uno alla volta, nell'ordine elencato, dall'inizio alla fine.
- phases/post_build
-
Sequenza opzionale. Rappresenta gli eventuali comandi che vengono CodeBuild eseguiti dopo la compilazione. Ad esempio, puoi usare Maven per impacchettare gli artefatti di compilazione in un file JAR o WAR oppure puoi inserire un'immagine Docker in Amazon ECR. Quindi puoi inviare una notifica di build tramite Amazon SNS.
- phases/post_build/commands
-
Obbligatorio
post_buildse specificato. Contiene una sequenza di scalari, in cui ogni scalare rappresenta un singolo comando che CodeBuild viene eseguito dopo la compilazione. CodeBuild esegue ogni comando, uno alla volta, nell'ordine elencato, dall'inizio alla fine.
reports
- report-group-name-or-arn
-
Sequenza opzionale. Specifica il gruppo di report a cui vengono inviati i report. Un progetto può annoverare al massimo cinque gruppi di report. Specificare l'ARN di un gruppo di report esistente o il nome di un nuovo gruppo di report. Se specificate un nome, CodeBuild crea un gruppo di report utilizzando il nome del progetto e il nome specificato nel formato.
<project-name>-<report-group-name>Il nome del gruppo di report può anche essere impostato utilizzando una variabile di ambiente nel buildspec, ad esempio.$REPORT_GROUP_NAMEPer ulteriori informazioni, consulta Denominazione dei gruppi di report. - reports/<report-group>/files
-
Sequenza obbligatoria. Rappresenta le collocazioni dei dati grezzi afferenti ai risultati di test generati dal report. Contiene una sequenza di scalari, con ogni scalare che rappresenta una posizione separata in cui è CodeBuild possibile trovare i file di test, rispetto alla posizione di build originale o, se impostata, a.
base-directoryLe posizioni possono includere quanto segue:-
Un solo file (ad esempio
my-test-report-file.json). -
Un solo file in una sottodirectory (ad esempio
omy-subdirectory/my-test-report-file.json).my-parent-subdirectory/my-subdirectory/my-test-report-file.json -
'**/*'rappresenta tutti i file in modo ricorsivo. -
rappresenta tutti i file in una sottodirectory denominata.my-subdirectory/*my-subdirectory -
rappresenta tutti i file in modo ricorsivo a partire da una sottodirectory denominata.my-subdirectory/**/*my-subdirectory
-
- reports/<report-group>/file-format
-
Mappatura opzionale. Rappresenta il formato del file di report. In assenza di specifica, viene utilizzato
JUNITXML. Questo valore non fa distinzione tra maiuscole e minuscole. I valori possibili sono:Rapporti sui test
-
CUCUMBERJSON -
Cucumber JSON
-
JUNITXML -
JUnit XML
-
NUNITXML -
NUnit XML
-
NUNIT3XML -
NUnit XML 3
-
TESTNGXML -
TestNG XML
-
VISUALSTUDIOTRX -
Visual Studio TRX
Rapporti sulla copertura del codice
-
CLOVERXML -
Clover XML
-
COBERTURAXML -
Copertura XML
-
JACOCOXML -
JaCoCo XML
-
SIMPLECOV -
SimpleCov JSON
-
- reports/<report-group>/base-directory
-
Mappatura opzionale. Rappresenta una o più directory di primo livello, relative alla posizione di build originale, che vengono CodeBuild utilizzate per determinare dove trovare i file di test non elaborati.
- reports/<report-group>/discard-paths
-
Facoltativo. Specifica se le directory dei file di report vengono appiattite nell'output. Se non è specificato o contiene
no, i file di report vengono generati con la loro struttura di directory intatta. Se contieneyes, tutti i file di test vengono inseriti nella stessa directory di output. Ad esempio, se un percorso di un risultato del test ècom/myapp/mytests/TestResult.xml, specificandoyesquesto file verrà posizionato in/TestResult.xml.
artefatti
Sequenza opzionale. Rappresenta informazioni su dove CodeBuild è possibile trovare l'output della build e su come CodeBuild prepararlo per il caricamento nel bucket di output S3. Questa sequenza non è necessaria se, ad esempio, stai creando e inviando un'immagine Docker ad Amazon ECR oppure esegui test unitari sul tuo codice sorgente, ma non lo compili.
Nota
I metadati di Amazon S3 hanno un' CodeBuild intestazione denominata x-amz-meta-codebuild-buildarn che contiene la CodeBuild build che pubblica gli buildArn artefatti su Amazon S3. buildArnViene aggiunto per consentire il tracciamento della fonte per le notifiche e per fare riferimento alla build da cui viene generato l'artefatto.
- artifacts/files
-
Sequenza obbligatoria. Rappresenta le posizioni contenenti gli artefatti di output della build nell'ambiente della build. Contiene una sequenza di scalari, ognuno dei quali rappresenta una posizione diversa dove CodeBuild può trovare gli artefatti dell'output della build rispetto alla posizione della build originale o, se impostata, alla directory di base. Le posizioni possono includere quanto segue:
-
Un solo file (ad esempio
my-file.jar). -
Un solo file in una sottodirectory (ad esempio
omy-subdirectory/my-file.jar).my-parent-subdirectory/my-subdirectory/my-file.jar -
'**/*'rappresenta tutti i file in modo ricorsivo. -
rappresenta tutti i file in una sottodirectory denominata.my-subdirectory/*my-subdirectory -
rappresenta tutti i file in modo ricorsivo a partire da una sottodirectory denominata.my-subdirectory/**/*my-subdirectory
Quando specificate le posizioni degli artefatti di output della build, CodeBuild potete individuare la posizione di compilazione originale nell'ambiente di compilazione. Non occorre anteporre le posizioni dell'output dell'artefatto della build al percorso verso la posizione della build originale, né specificare
./o valori simili. Se vuoi conoscere il percorso verso la posizione, puoi eseguire un comando comeecho $CODEBUILD_SRC_DIRdurante una build. La posizione di ciascun ambiente di build può essere leggermente diversa. -
- artifacts/name
-
Nome opzionale. Specifica un nome per l'artefatto della build. Questo nome si usa quando una delle seguenti affermazioni è vera.
-
Utilizzate l' CodeBuild API per creare le vostre build e il
overrideArtifactNameflag viene impostato sull'ProjectArtifactsoggetto quando un progetto viene aggiornato, creato un progetto o viene avviata una build. -
Si utilizza la CodeBuild console per creare le build, viene specificato un nome nel file buildspec e si seleziona Abilita il controllo delle versioni semantiche quando si crea o si aggiorna un progetto. Per ulteriori informazioni, consulta Creare un progetto di compilazione (console).
Puoi specificare un nome nel file buildspec calcolato in fase di creazione. Il nome specificato nel file buildspec utilizza il linguaggio di comando Shell. Ad esempio, è possibile aggiungere una data e un'ora al nome dell'artefatto in modo che sia sempre univoco. I nomi di artefatto univoci impediscono che gli artefatti vengano sovrascritti. Per ulteriori informazioni, consulta Linguaggio di comando Shell
. -
Questo è un esempio di un nome di artefatto a cui viene aggiunta la data di creazione dell'artefatto.
version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$(date +%Y-%m-%d) -
Questo è un esempio di nome di artefatto che utilizza una variabile di ambiente. CodeBuild Per ulteriori informazioni, consulta Variabili di ambiente degli ambienti di compilazione.
version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: myname-$AWS_REGION -
Questo è un esempio di nome di artefatto che utilizza una variabile di CodeBuild ambiente a cui è aggiunta la data di creazione dell'artefatto.
version: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: $AWS_REGION-$(date +%Y-%m-%d)
È possibile aggiungere informazioni sul percorso al nome in modo che gli artefatti denominati vengano inseriti nelle directory in base al percorso contenuto nel nome. In questo esempio, gli artefatti della build vengono inseriti nell'output sotto.
builds/<build number>/my-artifactsversion: 0.2 phases: build: commands: - rspec HelloWorld_spec.rb artifacts: files: - '**/*' name: builds/$CODEBUILD_BUILD_NUMBER/my-artifacts -
- artifacts/discard-paths
-
Facoltativo. Specifica se le directory degli artefatti di build vengono appiattite nell'output. Se non è specificato, o contiene
no, gli artefatti di build vengono generati con la loro struttura di directory intatta. Se contieneyes, tutti gli artefatti di build vengono inseriti nella stessa directory di output. Ad esempio, se un percorso di un file nell'artefatto di output della build ècom/mycompany/app/HelloWorld.java, specificandoyesil file verrà posizionato in/HelloWorld.java. - artifacts/base-directory
-
Mappatura opzionale. Rappresenta una o più directory di primo livello, relative alla posizione di compilazione originale, che CodeBuild vengono utilizzate per determinare quali file e sottodirectory includere nell'elemento di output della build. I valori validi includono:
-
Una sola directory di primo livello (ad esempio
my-directory). -
'my-directory*'rappresenta tutte le directory di primo livello i cui nomi iniziano conmy-directory.
Le directory di primo livello corrispondenti non sono incluse nell'artefatto dell'output della build, ma solo i file e le sottodirectory.
Puoi utilizzare
filesediscard-pathsper limitare ulteriormente i file e le sottodirectory inclusi. Ad esempio, per la seguente struttura di directory:. ├── my-build-1 │ └── my-file-1.txt └── my-build-2 ├── my-file-2.txt └── my-subdirectory └── my-file-3.txtE per la seguente sequenza
artifacts:artifacts: files: - '*/my-file-3.txt' base-directory: my-build-2Nell'artefatto di output della build sarebbero compresi la seguente sottodirectory e il seguente file:
. └── my-subdirectory └── my-file-3.txtMentre per la seguente sequenza
artifacts:artifacts: files: - '**/*' base-directory: 'my-build*' discard-paths: yesNell'artefatto di output della build sarebbero compresi i seguenti file:
. ├── my-file-1.txt ├── my-file-2.txt └── my-file-3.txt -
- artefatti/ percorsi di esclusione
-
Mappatura opzionale. Rappresenta uno o più percorsi, relativi a, che CodeBuild escluderanno gli
base-directoryartefatti della build. L'asterisco (*) individua zero o più caratteri di un componente del nome entro i limiti della cartella. Un doppio asterisco (**) corrisponde a zero o più caratteri di un componente del nome in tutte le directory.Di seguito sono riportati alcuni esempi di percorsi di esclusione:
-
Per escludere un file da tutte le directory:
"**/file-name/**/*" -
Per escludere tutte le cartelle dot:
"**/.*/**/*" -
Per escludere tutti i file dot:
"**/.*"
-
- artefatti/ enable-symlinks
-
Facoltativo. Se il tipo di output è
ZIP, specifica se i collegamenti simbolici interni vengono conservati nel file ZIP. Se contieneyes, tutti i collegamenti simbolici interni nel codice sorgente verranno conservati nel file ZIP degli artefatti. - artefatti/ prefisso s3
-
Facoltativo. Speciifica un prefisso utilizzato quando gli artefatti vengono emessi in un bucket Amazon S3 e il tipo di namespace è.
BUILD_IDQuando viene utilizzato, il percorso di output nel bucket è.<s3-prefix>/<build-id>/<name>.zip - artifacts/secondary-artifacts
-
Sequenza opzionale. Rappresenta una o più definizioni di artefatto come mappatura tra un identificatore dell'artefatto e una sua definizione. Ciascun identificatore di artefatto in questo blocco deve corrispondere a un artefatto definito nell'attributo
secondaryArtifactsdel progetto. Ogni diversa definizione presenta la stessa sintassi del bloccoartifactsillustrato in precedenza.Nota
La artifacts/filessequenza è sempre obbligatoria, anche quando sono definiti solo artefatti secondari.
Ad esempio, se un progetto presenta la seguente struttura:
{ "name": "sample-project", "secondaryArtifacts": [ { "type": "S3", "location": "<output-bucket1>", "artifactIdentifier": "artifact1", "name": "secondary-artifact-name-1" }, { "type": "S3", "location": "<output-bucket2>", "artifactIdentifier": "artifact2", "name": "secondary-artifact-name-2" } ] }Il buildspec avrà il seguente aspetto:
version: 0.2 phases: build: commands: - echo Building... artifacts: files: - '**/*' secondary-artifacts: artifact1: files: - directory/file1 name: secondary-artifact-name-1 artifact2: files: - directory/file2 name: secondary-artifact-name-2
cache
Sequenza opzionale. Rappresenta informazioni su dove CodeBuild è possibile preparare i file per il caricamento della cache in un bucket di cache S3. Questa sequenza non è obbligatoria se il tipo di cache del progetto è No Cache.
- cache/ chiave
-
Sequenza opzionale. Rappresenta la chiave primaria utilizzata per la ricerca o il ripristino di una cache. CodeBuild corrisponde esattamente alla chiave primaria.
Ecco un esempio della chiave:
key: npm-key-$(codebuild-hash-files package-lock.json) } - cache/ chiavi di riserva
-
Sequenza opzionale. Rappresenta un elenco di chiavi di fallback utilizzate in sequenza quando non è possibile trovare una cache utilizzando la chiave primaria. Sono supportate fino a cinque chiavi di fallback, ognuna delle quali viene abbinata mediante una ricerca per prefisso. Questa sequenza verrà ignorata se la chiave non viene fornita.
Ecco un esempio per le chiavi di riserva:
fallback-keys: - npm-key-$(codebuild-hash-files package-lock.json) } - npm-key- - npm- - cache/ azione
-
Sequenza opzionale. Specifica l'azione da eseguire sulla cache. I valori validi includono:
-
restoreche ripristina solo la cache senza salvare gli aggiornamenti. -
saveche salva solo la cache senza ripristinare una versione precedente.
Se non viene fornito alcun valore, l' CodeBuild impostazione predefinita esegue sia il ripristino che il salvataggio.
-
- cache/paths
-
Sequenza obbligatoria. Rappresenta le posizioni della cache. Contiene una sequenza di scalari, ciascuno dei quali rappresenta una posizione separata in cui è CodeBuild possibile trovare gli artefatti di output della build, rispetto alla posizione di build originale o, se impostata, alla directory di base. Le posizioni possono includere quanto segue:
-
Un solo file (ad esempio
my-file.jar). -
Un solo file in una sottodirectory (ad esempio
omy-subdirectory/my-file.jar).my-parent-subdirectory/my-subdirectory/my-file.jar -
'**/*'rappresenta tutti i file in modo ricorsivo. -
rappresenta tutti i file in una sottodirectory denominata.my-subdirectory/*my-subdirectory -
rappresenta tutti i file in modo ricorsivo a partire da una sottodirectory denominata.my-subdirectory/**/*my-subdirectory
-
Importante
Poiché una dichiarazione del file buildspec deve essere uno YAML valido, in una dichiarazione buildspec è importante la spaziatura. Se il numero di spazi nella dichiarazione buildspec non è valido, la build potrebbe non andare a buon fine immediatamente. È possibile usare un convalidatore YAML per verificare se le dichiarazioni buildspec sono YAML valide.
Se si utilizza il AWS CLI, or the AWS SDKs per dichiarare un buildspec quando si crea o si aggiorna un progetto di compilazione, il buildspec deve essere una singola stringa espressa in formato YAML, insieme agli spazi bianchi e ai caratteri di escape di nuova riga richiesti. Un esempio è riportato nella sezione successiva.
Se utilizzate le AWS CodePipeline console CodeBuild or invece di un file buildspec.yml, potete inserire comandi solo per la fase. build Invece di utilizzare la sintassi precedente, si elencano in una sola riga tutti i comandi da eseguire in fase di build. In caso di più comandi, separa ogni comando con && (ad esempio mvn test && mvn
package).
Puoi usare CodeBuild or CodePipeline consoles invece di un file buildspec.yml per specificare le posizioni degli artefatti di output della build nell'ambiente di compilazione. Invece di utilizzare la sintassi precedente, si elencano in una sola riga tutte le posizioni. Per più posizioni, separarne ognuna con una virgola (per esempio, buildspec.yml, target/my-app.jar).
Esempio di buildspec
Ecco un esempio di file buildspec.yml.
version: 0.2 env: variables: JAVA_HOME: "/usr/lib/jvm/java-8-openjdk-amd64" parameter-store: LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword phases: install: commands: - echo Entered the install phase... - apt-get update -y - apt-get install -y maven finally: - echo This always runs even if the update or install command fails pre_build: commands: - echo Entered the pre_build phase... - docker login -u User -p $LOGIN_PASSWORD finally: - echo This always runs even if the login command fails build: commands: - echo Entered the build phase... - echo Build started on `date` - mvn install finally: - echo This always runs even if the install command fails post_build: commands: - echo Entered the post_build phase... - echo Build completed on `date` reports: arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1: files: - "**/*" base-directory: 'target/tests/reports' discard-paths: no reportGroupCucumberJson: files: - 'cucumber/target/cucumber-tests.xml' discard-paths: yes file-format: CUCUMBERJSON # default is JUNITXML artifacts: files: - target/messageUtil-1.0.jar discard-paths: yes secondary-artifacts: artifact1: files: - target/artifact-1.0.jar discard-paths: yes artifact2: files: - target/artifact-2.0.jar discard-paths: yes cache: paths: - '/root/.m2/**/*'
Ecco un esempio del precedente buildspec, espresso come una singola stringa, da utilizzare con o. AWS CLI AWS SDKs
"version: 0.2\n\nenv:\n variables:\n JAVA_HOME: \"/usr/lib/jvm/java-8-openjdk-amd64\\"\n parameter-store:\n LOGIN_PASSWORD: /CodeBuild/dockerLoginPassword\n phases:\n\n install:\n commands:\n - echo Entered the install phase...\n - apt-get update -y\n - apt-get install -y maven\n finally:\n - echo This always runs even if the update or install command fails \n pre_build:\n commands:\n - echo Entered the pre_build phase...\n - docker login -u User -p $LOGIN_PASSWORD\n finally:\n - echo This always runs even if the login command fails \n build:\n commands:\n - echo Entered the build phase...\n - echo Build started on `date`\n - mvn install\n finally:\n - echo This always runs even if the install command fails\n post_build:\n commands:\n - echo Entered the post_build phase...\n - echo Build completed on `date`\n\n reports:\n reportGroupJunitXml:\n files:\n - \"**/*\"\n base-directory: 'target/tests/reports'\n discard-paths: false\n reportGroupCucumberJson:\n files:\n - 'cucumber/target/cucumber-tests.xml'\n file-format: CUCUMBERJSON\n\nartifacts:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n secondary-artifacts:\n artifact1:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n artifact2:\n files:\n - target/messageUtil-1.0.jar\n discard-paths: yes\n cache:\n paths:\n - '/root/.m2/**/*'"
Ecco un esempio dei comandi della build fase, da utilizzare con le console or. CodeBuild CodePipeline
echo Build started on `date` && mvn install
In questi esempi:
-
È impostata una variabile di ambiente personalizzata, in testo normale, con chiave
JAVA_HOMEe valore/usr/lib/jvm/java-8-openjdk-amd64. -
Una variabile di ambiente personalizzata denominata
dockerLoginPasswordyou memorizzata in Amazon EC2 Systems Manager Parameter Store viene referenziata più avanti nei comandi di compilazione utilizzando la chiaveLOGIN_PASSWORD. -
Non è possibile modificare questi nomi di fase della build. I comandi eseguiti in questo esempio sono
apt-get update -yandapt-get install -y maven(per installare Apache Maven),mvn install(per compilare, testare e impacchettare il codice sorgente in un elemento di output di compilazione e installare l'elemento di output della build nel suo repository interno),docker login(per accedere a Docker con la password che corrisponde al valore della variabile di ambiente personalizzata impostata indockerLoginPasswordAmazon Systems Manager EC2 Parameter Store) e diversi comandi.echoIechocomandi sono inclusi qui per mostrare come vengono CodeBuild eseguiti i comandi e l'ordine in cui vengono eseguiti. -
filesrappresenta i file da caricare nella posizione dell'output della build. In questo esempio, CodeBuild carica il singolo filemessageUtil-1.0.jar. Il filemessageUtil-1.0.jarsi trova nella relativa directory denominatatargetnell'ambiente di build. Poiché è specificatodiscard-paths: yes,messageUtil-1.0.jarviene caricato direttamente (non su una directorytargetintermedia). Il nome del filemessageUtil-1.0.jare il nome della relativa directorytargetsono basati sul modo in cui Apache Maven crea e archivia artefatti di output della build unicamente per questo esempio. Nei tuoi scenari, questi nomi di file e directory saranno differenti. -
reportsrappresenta due gruppi di report che generano report durante la compilazione:-
arn:aws:codebuild:your-region:your-aws-account-id:report-group/report-group-name-1specifica l'ARN di un gruppo di report. I risultati dei test generati dal framework di test si trovano nella directorytarget/tests/reports. Il formato dei file èJunitXmle il percorso non viene rimosso dai file contenenti i risultati dei test. -
reportGroupCucumberJsonspecifica un nuovo gruppo di report. Se il nome del progetto èmy-project, nel momento in cui si esegue una compilazione viene creato un gruppo di report denominatomy-project-reportGroupCucumberJson. I risultati dei test generati dal framework di test si trovano incucumber/target/cucumber-tests.xml. Il formato dei file di test èCucumberJsone il percorso non viene rimosso dai file contenenti i risultati dei test.
-
Versioni di buildspec
La seguente tabella elenca le versioni delle buildspec e le modifiche tra le versioni.
| Versione | Modifiche |
|---|---|
| 0.2 |
|
| 0.1 | Questa è la definizione iniziale del formato della specifica di build. |