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à.
Utilizza le informazioni in questo argomento per individuare, diagnosticare e risolvere problemi. Per informazioni su come registrare e monitorare CodeBuild le build per risolvere i problemi, consulta. Registrazione di log e monitoraggio
Argomenti
- Apache Maven compila artefatti di riferimento dal repository errato
- I comandi di compilazione vengono eseguiti come root per impostazione predefinita
- Le compilazioni potrebbero fallire quando i nomi dei file non sono U.S. Caratteri inglesi
- Le build potrebbero non riuscire quando si ottengono i parametri da Amazon EC2 Parameter Store
- Impossibile accedere al filtro branch nella CodeBuild console
- Impossibile visualizzare l'esito positivo o negativo della compilazione
- Lo stato della build non è stato segnalato al fornitore di origine
- Impossibile trovare e selezionare l'immagine di base della piattaforma Windows Server Core 2019
- I comandi precedenti nei file buildspec non vengono riconosciuti dai comandi successivi
- Errore "Access denied" (Accesso negato) durante il tentativo di eseguire il download della cache
- Errore: "BUILD_ _ UNABLE _TO_ CONTAINER _" quando si utilizza un'immagine di PULL build IMAGE personalizzata
- Errore: «Il contenitore di compilazione è stato trovato morto prima di completare la compilazione. Il contenitore di compilazione è morto perché aveva esaurito la memoria o l'immagine Docker non è supportata. ErrorCode: 500"
- Errore: "Impossibile connettersi al daemon Docker" quando si esegue una build
- Errore: "non CodeBuild è autorizzato a eseguire: sts:AssumeRole" durante la creazione o l'aggiornamento di un progetto di compilazione
- Errore: «Errore nella chiamata GetBucketAcl: il proprietario del bucket è cambiato o il ruolo del servizio non è più autorizzato a chiamare s3:» GetBucketAcl
- Errore "Failed to upload artifacts: Invalid arn" (Impossibile caricare artefatti: ARN non valido) durante l'esecuzione di una compilazione
- Errore: «Git clone non riuscito: impossibile accedere'your-repository-URL': problema con il SSL certificato: certificato autofirmato»
- Errore "The bucket you are attempting to access must be addressed using the specified endpoint" (Il bucket a cui tenti di accedere deve essere individuato tramite l'endpoint specificato) durante l'esecuzione di una compilazione
- Errore: "This build image requires selecting at least one runtime version." (Questa immagine di compilazione richiede la selezione di almeno una versione runtime.)
- Errore: "QUEUED: INSUFFICIENT _SUBNET" quando una compilazione in una coda di compilazione fallisce
- Errore: «Impossibile scaricare la cache: RequestError: Invio della richiesta non riuscito a causa di: x509: impossibile caricare le radici del sistema e nessuna root fornita»
- Errore: «Impossibile scaricare il certificato da S3. AccessDenied»
- Errore "Unable to Locate Credentials" (Impossibile individuare le credenziali)
- RequestError errore di timeout durante l'esecuzione CodeBuild in un server proxy
- La bourne shell (sh) deve esistere nelle immagini di compilazione
- Avvertenza: "Skipping install of runtimes. Runtime version selection is not supported by this build image" (L'installazione dei runtime non viene eseguita. L'immagine di compilazione non supporta la selezione delle versioni dei runtime) durante l’esecuzione di una compilazione
- Errore: «Impossibile verificare JobWorker l'identità» all'apertura della CodeBuild console
- Avvio della compilazione non riuscito
- Accesso ai GitHub metadati nelle build memorizzate nella cache locale
- AccessDenied: Il proprietario del bucket per il gruppo di report non corrisponde al proprietario del bucket S3...
Apache Maven compila artefatti di riferimento dal repository errato
Problema: quando usi Maven con un ambiente di compilazione Java AWS CodeBuild fornito, Maven estrae le dipendenze di build e plugin dal repository Maven centrale sicuro all'indirizzo https://repo1.maven.org/maven2.pom.xml
del progetto di compilazione dichiara esplicitamente altre posizioni alternative da utilizzare.
Possibile causa: gli ambienti di CodeBuild compilazione Java forniti includono un file denominato preinstallato nella directory dell'ambiente di compilazione. settings.xml
/root/.m2
Questo file settings.xml
contiene le seguenti dichiarazioni, che indicano a Maven di eseguire sempre il pull delle dipendenze di compilazione e di plugin da un repository Maven centrale protetto disponibile all'indirizzo https://repo1.maven.org/maven2
<settings>
<activeProfiles>
<activeProfile>securecentral</activeProfile>
</activeProfiles>
<profiles>
<profile>
<id>securecentral</id>
<repositories>
<repository>
<id>central</id>
<url>https://repo1.maven.org/maven2</url>
<releases>
<enabled>true</enabled>
</releases>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<url>https://repo1.maven.org/maven2</url>
<releases>
<enabled>true</enabled>
</releases>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
</settings>
Soluzione consigliata: procedi come segue:
-
Aggiungere un file
settings.xml
al codice sorgente. -
In questo file
settings.xml
utilizzare il formatosettings.xml
precedente come guida per dichiarare i repository da cui si desidera che Maven esegua il pull delle dipendenze di compilazione e di plugin. -
Nella
install
fase del progetto di compilazione, chiedi di CodeBuild copiare ilsettings.xml
file nella directory dell'ambiente di compilazione./root/.m2
Considerare ad esempio il seguente frammento di un filebuildspec.yml
che dimostra questo comportamento.version 0.2 phases: install: commands: - cp ./settings.xml /root/.m2/settings.xml
I comandi di compilazione vengono eseguiti come root per impostazione predefinita
Problema: AWS CodeBuild esegue i comandi di compilazione come utente root. Ciò avviene anche se il Dockerfile dell'immagine di compilazione correlata imposta l'istruzione USER
su un altro utente.
Causa: per impostazione predefinita, CodeBuild esegue tutti i comandi di build come utente root.
Soluzione consigliata: nessuna.
Le compilazioni potrebbero fallire quando i nomi dei file non sono U.S. Caratteri inglesi
Problema: quando si esegue una build che utilizza file con nomi di file che contengono nomi non U.S. Caratteri inglesi (ad esempio caratteri cinesi), la compilazione fallisce.
Possibile causa: gli ambienti di compilazione forniti da AWS CodeBuild hanno le impostazioni locali predefinite impostate suPOSIX
. POSIX
le impostazioni di localizzazione sono meno compatibili con CodeBuild i nomi di file che contengono dati non U.S. caratteri inglesi e possono causare il fallimento delle build correlate.
Soluzione consigliata: aggiungi i seguenti comandi alla sezione pre_build
del file buildspec. Questi comandi fanno sì che l'ambiente di compilazione utilizzi l'inglese americano UTF -8 per le impostazioni di localizzazione, che è più compatibile con CodeBuild i nomi di file che contengono nomi non U.S. Caratteri inglesi.
Per gli ambienti di compilazione basati su Ubuntu:
pre_build:
commands:
- export LC_ALL="en_US.UTF-8"
- locale-gen en_US en_US.UTF-8
- dpkg-reconfigure locales
Per ambienti di compilazione basati su Amazon Linux:
pre_build:
commands:
- export LC_ALL="en_US.utf8"
Le build potrebbero non riuscire quando si ottengono i parametri da Amazon EC2 Parameter Store
Problema: quando una build tenta di ottenere il valore di uno o più parametri memorizzati in Amazon EC2 Parameter Store, la compilazione fallisce nella DOWNLOAD_SOURCE
fase con l'erroreParameter does not
exist
.
Possibile causa: il ruolo di servizio su cui si basa il progetto di compilazione non è autorizzato a richiamare l'ssm:GetParameters
azione oppure il progetto di compilazione utilizza un ruolo di servizio generato AWS CodeBuild e che consente di richiamare l'ssm:GetParameters
azione, ma i parametri hanno nomi che non iniziano con/CodeBuild/
.
Soluzioni consigliate:
-
Se il ruolo di servizio non è stato generato da CodeBuild, aggiorna la sua definizione per consentire di CodeBuild richiamare l'
ssm:GetParameters
azione. La seguente dichiarazione di policy consente ad esempio di chiamare l'azionessm:GetParameters
per ottenere parametri con nomi che iniziano con/CodeBuild/
.{ "Version": "2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:
REGION_ID
:ACCOUNT_ID
:parameter/CodeBuild/*" } ] } -
Se il ruolo di servizio è stato generato da CodeBuild, aggiorna la sua definizione per consentire l'accesso CodeBuild ai parametri in Amazon EC2 Parameter Store con nomi diversi da quelli che iniziano con
/CodeBuild/
. La seguente dichiarazione di policy consente ad esempio di chiamare l'azionessm:GetParameters
per ottenere parametri con il nome specificato:{ "Version": "2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:
REGION_ID
:ACCOUNT_ID
:parameter/PARAMETER_NAME
" } ] }
Impossibile accedere al filtro branch nella CodeBuild console
Problema: l'opzione del filtro branch non è disponibile nella console quando si crea o si aggiorna un AWS CodeBuild progetto.
Possibile causa: l'opzione di filtro dei rami è obsoleto. È stata sostituita dai gruppi di filtri webhook, che forniscono un maggiore controllo sugli eventi webhook che attivano una nuova build in. CodeBuild
Soluzione consigliata: per effettuare la migrazione di un filtro dei rami creato prima dell'introduzione dei filtri di webhook, creare un gruppo di filtri di webhook contenente un filtro HEAD_REF
con l'espressione regolare ^refs/heads/
. Ad esempio, se l'espressione regolare del tuo filtro dei rami era branchName
$^branchName$
, l'espressione regolare aggiornata da inserire nel filtro HEAD_REF
sarà ^refs/heads/branchName$
. Per ulteriori informazioni, consulta Eventi webhook Bitbucket e Filtra gli eventi GitHub webhook (console).
Impossibile visualizzare l'esito positivo o negativo della compilazione
Problema: non riesci a visualizzare se una compilazione ripetuta ha avuto esito positivo o negativo.
Possibile causa: l'opzione per la segnalazione dello stato della compilazione non è abilitata.
Soluzioni consigliate: abilita lo stato di compilazione del report quando crei o aggiorni un CodeBuild progetto. Questa opzione indica CodeBuild di riportare lo stato quando si attiva una build. Per ulteriori informazioni, vedere reportBuildStatusnel AWS CodeBuild APIReference.
Lo stato della build non è stato segnalato al fornitore di origine
Problema: dopo aver consentito la segnalazione dello stato della build a un provider di origine, ad GitHub esempio Bitbucket, lo stato della build non viene aggiornato.
Possibile causa: l'utente associato al provider di origine non dispone dell'accesso in scrittura al repository.
Soluzioni consigliate: per poter segnalare lo stato della build al provider di origine, l'utente associato al provider di origine deve disporre dell'accesso in scrittura al repository. Se l'utente non dispone dell'accesso in scrittura, lo stato della build non può essere aggiornato. Per ulteriori informazioni, consulta Accesso al provider di origine.
Impossibile trovare e selezionare l'immagine di base della piattaforma Windows Server Core 2019
Problema: non è possibile trovare o selezionare l'immagine di base della piattaforma Windows Server Core 2019.
Possibile causa: stai utilizzando una AWS regione che non supporta questa immagine.
Soluzioni consigliate: utilizza una delle seguenti AWS regioni in cui è supportata l'immagine di base della piattaforma Windows Server Core 2019:
-
Stati Uniti orientali (Virginia settentrionale)
-
Stati Uniti orientali (Ohio)
-
US West (Oregon)
-
Europa (Irlanda)
I comandi precedenti nei file buildspec non vengono riconosciuti dai comandi successivi
Problemi: i risultati di uno o più comandi nel file buildspec non vengono riconosciuti dai comandi successivi nello stesso file buildspec. È ad esempio possibile che un comando imposti una variabile di ambiente locale, ma che una successiva esecuzione del comando non riesca a recuperare il valore di tale variabile di ambiente locale.
Possibile causa: nella versione 0.1 del file buildspec, AWS 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. Per impostazione predefinita, non è dunque possibile eseguire un singolo comando che si basa sullo stato di qualsiasi comando precedente.
Soluzioni consigliate: ti suggeriamo di utilizzare la versione 0.2 della specifica di compilazione, che risolve questo problema. Se devi utilizzare la versione 0.1 della specifica di compilazione, ti consigliamo di usare l'operatore di concatenazione del comando shell, ad esempio &&
in Linux, per combinare più comandi in un singolo comando. In alternativa, includi uno script della shell nel codice sorgente che contiene più comandi, quindi chiama tale script della shell da un singolo comando nel file buildspec. Per ulteriori informazioni, consulta Shell e comandi negli ambienti di compilazione e Variabili di ambiente degli ambienti di compilazione.
Errore "Access denied" (Accesso negato) durante il tentativo di eseguire il download della cache
Problema: quando tenti di scaricare la cache in un progetto di compilazione con la cache abilitata, viene visualizzato l'errore Access denied
.
Possibili cause:
-
Hai appena configurato il caching come parte del progetto di compilazione.
-
La cache è stata recentemente invalidata tramite.
InvalidateProjectCache
API -
Il ruolo di servizio utilizzato da CodeBuild non dispone
s3:GetObject
s3:PutObject
delle autorizzazioni per il bucket S3 che contiene la cache.
Soluzione consigliata: nel caso sia il primo utilizzo, è normale visualizzare questo errore subito dopo l'aggiornamento della configurazione della cache. Se l'errore persiste, verifica se il ruolo del servizio dispone delle autorizzazioni s3:GetObject
e s3:PutObject
per il bucket S3 con la cache. Per ulteriori informazioni, consulta Specificare le autorizzazioni S3 nella Amazon S3 Developer Guide.
Errore: "BUILD_ _ UNABLE _TO_ CONTAINER _" quando si utilizza un'immagine di PULL build IMAGE personalizzata
Problema: quando tenti di eseguire una compilazione che utilizza un'immagine di compilazione personalizzata, la compilazione ha esito negativo e viene restituito l'errore BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE
.
- Causa possibile: la dimensione complessiva non compressa dell'immagine di compilazione è maggiore dello spazio disponibile su disco del tipo di calcolo dell'ambiente di compilazione. Per controllare la dimensione dell'immagine di compilazione, utilizzare Docker per eseguire il comando
docker images
. Per un elenco dello spazio su disco disponibile per tipo di calcolo, consulta Modi e tipi di calcolo dell'ambiente di creazione.REPOSITORY
:TAG
-
Soluzione consigliata: utilizza un tipo di elaborazione più grande con più spazio su disco disponibile o riduci le dimensioni dell'immagine di build personalizzata.
- Possibile causa: AWS CodeBuild non dispone dell'autorizzazione per estrarre l'immagine di build dal tuo Amazon Elastic Container Registry (AmazonECR).
-
Soluzione consigliata: aggiorna le autorizzazioni nel tuo repository in Amazon in ECR modo da CodeBuild poter inserire l'immagine di build personalizzata nell'ambiente di compilazione. Per ulteriori informazioni, consulta la ECREsempio Amazon.
- Possibile causa: l'ECRimmagine Amazon che hai richiesto non è disponibile nella AWS regione utilizzata dal tuo AWS account.
-
Soluzione consigliata: usa un'ECRimmagine Amazon che si trova nella stessa AWS regione di quella utilizzata dal tuo AWS account.
- Possibile causa: stai utilizzando un registro privato in un paese VPC che non dispone di accesso pubblico a Internet. CodeBuild non è possibile estrarre un'immagine da un indirizzo IP privato in unVPC. Per ulteriori informazioni, consulta Registro privato con AWS Secrets Manager esempio per CodeBuild.
-
Soluzione consigliata: se utilizzi un registro privato in unVPC, assicurati che disponga di VPC un accesso pubblico a Internet.
- Possibile causa: se il messaggio di errore contiene "toomanyrequests«e l'immagine è ottenuta da Docker Hub, questo errore indica che è stato raggiunto il limite di pull di Docker Hub.
-
Soluzione consigliata: utilizza un registro privato Docker Hub o ottieni la tua immagine da AmazonECR. Per ulteriori informazioni sull'utilizzo di un registro privato, consulta Registro privato con AWS Secrets Manager esempio per CodeBuild. Per ulteriori informazioni sull'uso di AmazonECR, consultaECREsempio Amazon per CodeBuild .
Errore: «Il contenitore di compilazione è stato trovato morto prima di completare la compilazione. Il contenitore di compilazione è morto perché aveva esaurito la memoria o l'immagine Docker non è supportata. ErrorCode: 500"
Problema: quando si tenta di utilizzare un contenitore Microsoft Windows o Linux in AWS CodeBuild, questo errore si verifica durante la PROVISIONING fase.
Possibili cause:
-
La versione del sistema operativo del contenitore non è supportata da CodeBuild.
-
HTTP_PROXY
,HTTPS_PROXY
o entrambi sono specificati nel container.
Soluzioni consigliate:
-
Per Microsoft Windows, usa un contenitore Windows con un sistema operativo contenitore (versione 10.0.14393.2125)microsoft/windowsservercore:10.0.x (for example, microsoft/windowsservercore.
-
Per Linux, cancella
HTTPS_PROXY
le impostazioniHTTP_PROXY
e nell'immagine Docker o specifica la configurazione nel tuo progetto di build. VPC
Errore: "Impossibile connettersi al daemon Docker" quando si esegue una build
Problema: la tua compilazione ha esito negativo e ricevi un errore simile a Cannot connect to the Docker daemon
at unix:/var/run/docker.sock. Is the docker daemon running?
nel log di compilazione.
Possibile causa: la tua compilazione non è in esecuzione in modalità con privilegi.
Soluzione consigliata: per correggere questo errore, devi abilitare la modalità privilegiata e aggiornare il buildspec utilizzando le seguenti istruzioni.
Per eseguire la build in modalità privilegiata, segui questi passaggi:
-
Apri la CodeBuild console all'indirizzo https://console.aws.amazon.com/codebuild/
. -
Nel pannello di navigazione, scegli Crea progetti, quindi scegli il tuo progetto di compilazione.
-
In Modifica, scegliere Ambiente.
-
Scegli Additional configuration (Configurazione aggiuntiva).
-
Da Privileged, seleziona Abilita questo flag se desideri creare immagini Docker o desideri che le tue build ottengano privilegi elevati. .
-
Selezionare Update environment (Aggiorna ambiente).
-
Scegliere Avvia compilazione per ritentare la compilazione della build.
Dovrai anche avviare il demone Docker all'interno del tuo contenitore. La install
fase delle specifiche di compilazione potrebbe essere simile a questa.
phases:
install:
commands:
- nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2 &
- timeout 15 sh -c "until docker info; do echo .; sleep 1; done"
Per ulteriori informazioni sui driver di storage OverlayFS a cui si fa riferimento nel file buildspec, consulta Utilizzare il driver di storage OverlayFS
Nota
Se il sistema operativo di base è Alpine Linux, in buildspec.yml
aggiungere l'argomento -t
a timeout
:
- timeout -t 15 sh -c "until docker info; do echo .; sleep 1; done"
Per ulteriori informazioni su come creare ed eseguire un'immagine Docker utilizzando, consulta. AWS CodeBuildDocker in un esempio di immagine personalizzato per CodeBuild
Errore: "non CodeBuild è autorizzato a eseguire: sts:AssumeRole" durante la creazione o l'aggiornamento di un progetto di compilazione
Problema: quando tenti di creare o aggiornare un progetto di compilazione, viene visualizzato l'errore Code:InvalidInputException,
Message:CodeBuild is not authorized to perform: sts:AssumeRole on
arn:aws:iam::
.account-ID
:role/service-role-name
Possibili cause:
-
Il AWS Security Token Service (AWS STS) è stato disattivato per la AWS regione in cui si sta tentando di creare o aggiornare il progetto di compilazione.
-
Il ruolo AWS CodeBuild di servizio associato al progetto di compilazione non esiste o non dispone di autorizzazioni sufficienti per essere considerato attendibile. CodeBuild
Soluzioni consigliate:
-
Assicurati che AWS STS sia attivato per la AWS regione in cui stai tentando di creare o aggiornare il progetto di compilazione. Per ulteriori informazioni, consulta Attivazione e disattivazione AWS STS in una AWS regione nella Guida per l'utente. IAM
-
Assicurati che il ruolo di CodeBuild servizio di destinazione esista nel tuo account. AWS Se non utilizzi la console, assicurati di non aver digitato erroneamente l'Amazon Resource Name (ARN) del ruolo di servizio quando hai creato o aggiornato il progetto di build.
-
Assicurati che il ruolo di CodeBuild servizio di destinazione disponga di autorizzazioni sufficienti per essere considerato attendibile. CodeBuild Per ulteriori informazioni, consulta la dichiarazione di policy per relazioni di fiducia in Consentono CodeBuild di interagire con altri AWS servizi.
Errore: «Errore nella chiamata GetBucketAcl: il proprietario del bucket è cambiato o il ruolo del servizio non è più autorizzato a chiamare s3:» GetBucketAcl
Problema: quando esegui una build, viene visualizzato un errore circa la modifica della proprietà di un bucket S3 e delle autorizzazioni GetBucketAcl
.
Possibile causa: hai aggiunto le s3:GetBucketLocation
autorizzazioni s3:GetBucketAcl
and al tuo ruolo. IAM Queste autorizzazioni garantiscono la sicurezza del bucket S3 del progetto e garantiscono che solo tu puoi accedervi. Dopo aver aggiunto queste autorizzazioni, il proprietario del bucket S3 cambia.
Soluzione consigliata: verifica di essere il proprietario del bucket S3, quindi aggiungi nuovamente le autorizzazioni al tuo ruolo. IAM Per ulteriori informazioni, consulta Accesso sicuro ai bucket S3.
Errore "Failed to upload artifacts: Invalid arn" (Impossibile caricare artefatti: ARN non valido) durante l'esecuzione di una compilazione
Problema: quando esegui una compilazione , la fase della compilazione UPLOAD_ARTIFACTS
non riesce con l'errore Failed to
upload artifacts: Invalid arn
.
Possibile causa: il bucket di output S3 (il bucket in cui AWS CodeBuild memorizza l'output della build) si trova in una AWS regione diversa da quella del progetto di build. CodeBuild
Soluzione consigliata: aggiorna le impostazioni del progetto di build in modo che punti a un bucket di output che si trova nella stessa AWS regione del progetto di build.
Errore: «Git clone non riuscito: impossibile accedere'your-repository-URL'
: problema con il SSL certificato: certificato autofirmato»
Problema: quando tenti di eseguire un progetto di compilazione, la compilazione non riesce e restituisce questo errore.
Possibile causa: il repository di origine dispone di un certificato autofirmato, ma non hai scelto l'installazione del certificato dal bucket S3 come parte del progetto di compilazione.
Soluzioni consigliate:
-
Modifica il progetto. Per Certificate (Certificato), scegli Install certificate from S3 (Installa certificato da S3). Per Bucket of certificate, scegli il bucket S3 in cui è archiviato il SSL certificato. Per Object key of certificate (Chiave oggetto del certificato), immetti il nome della chiave dell'oggetto S3.
-
Modifica il progetto. Seleziona Non sicuro SSL per ignorare gli SSL avvisi durante la connessione al repository del progetto Enterprise Server. GitHub
Nota
Si consiglia di utilizzare Insecure SSL solo per i test. Non deve essere utilizzato in un ambiente di produzione.
Errore "The bucket you are attempting to access must be addressed using the specified endpoint" (Il bucket a cui tenti di accedere deve essere individuato tramite l'endpoint specificato) durante l'esecuzione di una compilazione
Problema: quando esegui una compilazione , la fase della compilazione DOWNLOAD_SOURCE
non riesce con l'errore The bucket you
are attempting to access must be addressed using the specified endpoint. Please send
all future requests to this endpoint
.
Possibile causa: il codice sorgente predefinito è archiviato in un bucket S3 e quel bucket si trova in una AWS regione diversa dal progetto di compilazione. AWS CodeBuild
Soluzione consigliata: aggiorna le impostazioni del progetto di compilazione in modo che punti a un bucket contenente il codice sorgente precompilato. Assicurati che il bucket si trovi nella stessa AWS regione del progetto di compilazione.
Errore: "This build image requires selecting at least one runtime version." (Questa immagine di compilazione richiede la selezione di almeno una versione runtime.)
Problema: quando esegui una compilazione , la fase della compilazione DOWNLOAD_SOURCE
non riesce con l'errore YAML_FILE_ERROR:
This build image requires selecting at least one runtime version
.
Possibile causa: la tua build utilizza la versione 1.0 o successiva dell'immagine standard Amazon Linux 2 (AL2) o la versione 2.0 o successiva dell'immagine standard di Ubuntu e non è specificato un runtime nel file buildspec.
Soluzione consigliata: se usi l'immagine aws/codebuild/standard:2.0
CodeBuild gestita, devi specificare una versione di runtime nella runtime-versions
sezione del file buildspec. Ad esempio, è possibile utilizzare il seguente file buildspec per un progetto che utilizza: PHP
version: 0.2
phases:
install:
runtime-versions:
php: 7.3
build:
commands:
- php --version
artifacts:
files:
- README.md
Nota
Se specifichi una runtime-versions
sezione 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
.»
Per ulteriori informazioni, consulta Specify runtime versions in the buildspec file.
Errore: "QUEUED: INSUFFICIENT _SUBNET" quando una compilazione in una coda di compilazione fallisce
Problema: una compilazione in una coda di compilazione ha esito negativo con un errore simile a QUEUED: INSUFFICIENT_SUBNET
.
Possibili cause: il IPv4 CIDR blocco specificato per l'utente VPC utilizza un indirizzo IP riservato. I primi quattro indirizzi IP e l'ultimo indirizzo IP in ogni CIDR blocco di sottorete non sono disponibili per l'uso e non possono essere assegnati a un'istanza. Ad esempio, in una sottorete con CIDR blocco10.0.0.0/24
, sono riservati i seguenti cinque indirizzi IP:
-
10.0.0.0:
: indirizzo di rete. -
10.0.0.1
: Riservato da AWS per il VPC router. -
10.0.0.2
: Riservato da AWS. L'indirizzo IP del DNS server è sempre la base dell'intervallo di VPC rete più due; tuttavia, riserviamo anche la base di ogni intervallo di sottoreti più due. In VPCs caso di CIDR blocchi multipli, l'indirizzo IP del DNS server si trova nel CIDR primario. Per ulteriori informazioni, consulta Amazon DNS server nella Amazon VPC User Guide. -
10.0.0.3
: Riservato da AWS per utilizzi futuri. -
10.0.0.255
: indirizzo di trasmissione di rete. Non supportiamo la trasmissione in unVPC. Questo indirizzo è riservato.
Soluzioni consigliate: Verifica se VPC utilizzi un indirizzo IP riservato. Sostituisci qualsiasi indirizzo IP riservato con uno non riservato. Per ulteriori informazioni, consulta VPC la sezione relativa al dimensionamento della sottorete nella Amazon VPC User Guide.
Errore: «Impossibile scaricare la cache: RequestError: Invio della richiesta non riuscito a causa di: x509: impossibile caricare le radici del sistema e nessuna root fornita»
Problema: quando tenti di eseguire un progetto di compilazione, la compilazione non riesce e restituisce questo errore.
Possibile causa: hai configurato il caching come parte del progetto di compilazione e utilizzi un'immagine Docker precedente che include un certificato root scaduto.
Soluzione consigliata: aggiorna l'immagine Docker utilizzata nel progetto. AWS CodeBuild Per ulteriori informazioni, consulta Immagini Docker fornite da CodeBuild.
Errore: «Impossibile scaricare il certificato da S3. AccessDenied»
Problema: quando tenti di eseguire un progetto di compilazione, la compilazione non riesce e restituisce questo errore.
Possibili cause:
-
Hai scelto il bucket S3 errato per il certificato.
-
Hai immesso la chiave dell'oggetto errata per il certificato.
Soluzioni consigliate:
-
Modifica il progetto. Per Bucket of certificate, scegli il bucket S3 in cui è SSL archiviato il certificato.
-
Modifica il progetto. Per Object key of certificate (Chiave oggetto del certificato), immetti il nome della chiave dell'oggetto S3.
Errore "Unable to Locate Credentials" (Impossibile individuare le credenziali)
Problema: quando si tenta di eseguire AWS CLI, utilizzare o chiamare un AWS
SDK altro componente simile come parte di una build, si ottengono errori di compilazione direttamente correlati al componente AWS CLI AWS SDK, o. Ad esempio, potresti ricevere un errore di compilazione come Unable to locate credentials
.
Possibili cause:
-
La versione del componente AWS CLI AWS SDK, o nell'ambiente di compilazione è incompatibile con AWS CodeBuild.
-
Stai eseguendo un contenitore Docker all'interno di un ambiente di compilazione che utilizza Docker e il contenitore non ha accesso alle AWS credenziali per impostazione predefinita.
Soluzioni consigliate:
-
Assicurati che il tuo ambiente di compilazione abbia la versione seguente o successiva del componente AWS CLI AWS SDK, or.
-
AWS CLI: 1.10.47
-
AWS SDKper C++: 0.2.19
-
AWS SDKper Go: 1.2.5
-
AWS SDKper Java: 1.11.16
-
AWS SDKper JavaScript: 2.4.7
-
AWS SDKperPHP: 3.18.28
-
AWS SDKper Python (Boto3): 1.4.0
-
AWS SDKper Ruby: 2.3.22
-
Botocore: 1.4.37
-
Nucleo: 3.2.6-beta CLR
-
Node.js: 2.4.7
-
-
Se devi eseguire un contenitore Docker in un ambiente di compilazione e il contenitore richiede AWS credenziali, devi passare le credenziali dall'ambiente di compilazione al contenitore. Nel file buildspec, includere un comando Docker
run
come il seguente. In questo esempio viene utilizzato il comandoaws s3 ls
per elencare i bucket S3 disponibili. L'-e
opzione passa attraverso le variabili di ambiente necessarie al contenitore per accedere alle credenziali. AWSdocker run -e AWS_DEFAULT_REGION -e AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
your-image-tag
aws s3 ls -
Se stai creando un'immagine Docker e la build richiede AWS credenziali (ad esempio, per scaricare un file da Amazon S3), devi passare le credenziali dall'ambiente di compilazione al processo di compilazione Docker come segue.
-
Nel Dockerfile del codice sorgente per l'immagine Docker specificare le seguenti istruzioni
ARG
.ARG AWS_DEFAULT_REGION ARG AWS_CONTAINER_CREDENTIALS_RELATIVE_URI
-
Nel file buildspec, includere un comando Docker
build
come il seguente. Le--build-arg
opzioni impostano le variabili di ambiente necessarie per il processo di compilazione Docker per accedere alle credenziali. AWSdocker build --build-arg AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION --build-arg AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI -t
your-image-tag
.
-
RequestError errore di timeout durante l'esecuzione CodeBuild in un server proxy
Problema: viene visualizzato un errore RequestError
simile a uno dei seguenti:
-
RequestError: send request failed caused by: Post https://logs.<your-region>.amazonaws.com/: dial tcp 52.46.158.105:443: i/o timeout
da CloudWatch Logs. -
Error uploading artifacts: RequestError: send request failed caused by: Put https://
da Amazon S3.your-bucket
.s3.your-aws-region
.amazonaws.com/*: dial tcp 52.219.96.208:443: connect: connection refused
Possibili cause:
-
ssl-bump
non è configurato correttamente. -
La policy di sicurezza della tua organizzazione non consente di utilizzare
ssl_bump
. -
Il file di specifiche di compilazione non ha impostazioni proxy specificate mediante un elemento
proxy
.
Soluzioni consigliate:
-
Assicurati che
ssl-bump
sia correttamente configurato. Se per il tuo server proxy utilizzi Squid, consulta Configura Squid come server proxy esplicito. -
Segui questi passaggi per utilizzare endpoint privati per Amazon S3 CloudWatch e Logs:
-
Nella tabella di routing della sottorete privata, rimuovi la regola aggiunta che instrada sul server proxy il traffico destinato a Internet. Per informazioni, consulta Creating a subnet in your VPC nella Amazon VPC User Guide.
-
Crea un endpoint Amazon S3 privato e un endpoint CloudWatch Logs e associali alla sottorete privata del tuo Amazon. VPC Per informazioni, consulta i servizi VPC endpoint nella Amazon VPC User Guide.
-
Conferma che l'opzione Abilita DNS nome privato nel tuo Amazon VPC è selezionata. Per ulteriori informazioni, consulta Creazione di un endpoint di interfaccia nella Amazon VPC User Guide.
-
-
Se non utilizzi
ssl-bump
per un server proxy esplicito, aggiungi una configurazione proxy al file di specifiche di compilazione utilizzando un elementoproxy
. Per ulteriori informazioni, consulta Esegui CodeBuild in un server proxy esplicito e Sintassi buildspec.version: 0.2 proxy: upload-artifacts: yes logs: yes phases: build: commands:
La bourne shell (sh) deve esistere nelle immagini di compilazione
Problema: stai utilizzando un'immagine di build che non è stata fornita da e AWS CodeBuild le tue build hanno esito negativo con il messaggio. Build container found
dead before completing the build
Possibile causa: La Bourne shell (sh
) non è inclusa nell'immagine di build. CodeBuild deve sh
eseguire comandi e script di compilazione.
Soluzione consigliata: se sh
non è presente nell'immagine di compilazione, assicurati di includerla prima di iniziare altre build che utilizzano l'immagine. (include CodeBuild già le immagini sh
di compilazione).
Avvertenza: "Skipping install of runtimes. Runtime version selection is not supported by this build image" (L'installazione dei runtime non viene eseguita. L'immagine di compilazione non supporta la selezione delle versioni dei runtime) durante l’esecuzione di una compilazione
Problema: quando esegui una compilazione, il log di compilazione contiene questa avvertenza.
Possibile causa: la build non utilizza la versione 1.0 o successiva dell'immagine standard Amazon Linux 2 (AL2) o la versione 2.0 o successiva dell'immagine standard di Ubuntu e un runtime è specificato in una runtime-versions
sezione del file buildspec.
Soluzione consigliata: verificare che il file buildspec non contenga una sezione runtime-versions
. La runtime-versions
sezione è richiesta solo se utilizzi l'immagine standard di Amazon Linux 2 (AL2) o successiva o l'immagine standard di Ubuntu versione 2.0 o successiva.
Errore: «Impossibile verificare JobWorker l'identità» all'apertura della CodeBuild console
Problema: quando si apre la CodeBuild console, viene visualizzato il messaggio di errore «Impossibile verificare l' JobWorker identità».
Possibile causa: il IAM ruolo utilizzato per l'accesso alla console ha un tag jobId
come chiave. Questa chiave di tag è riservata a CodeBuild e, se presente, causerà questo errore.
Soluzione consigliata: modifica tutti i tag di IAM ruolo personalizzati che hanno la chiave jobId
per avere una chiave diversa, ad esempiojobIdentifier
.
Avvio della compilazione non riuscito
Problema: quando si avvia una build, viene visualizzato un messaggio di errore Build to start.
Possibile causa: è stato raggiunto il numero di build simultanee.
Soluzioni consigliate: attendi il completamento delle altre build oppure aumenta il limite di compilazioni simultanee per il progetto e riavvia la compilazione. Per ulteriori informazioni, consulta Configurazione del progetto.
Accesso ai GitHub metadati nelle build memorizzate nella cache locale
Problema: in alcuni casi, la directory.git in una build memorizzata nella cache è un file di testo e non una directory.
Possibili cause: quando la memorizzazione nella cache locale dei sorgenti è abilitata per una build, CodeBuild crea un gitlink per la directory. .git
Ciò significa che la .git
directory è in realtà un file di testo contenente il percorso della directory.
Soluzioni consigliate: in tutti i casi, utilizzate il seguente comando per ottenere la directory dei metadati Git. Questo comando funzionerà indipendentemente dal formato di.git
:
git rev-parse --git-dir
AccessDenied: Il proprietario del bucket per il gruppo di report non corrisponde al proprietario del bucket S3...
Problema: quando carica i dati di test su un bucket Amazon S3 CodeBuild , non è in grado di scrivere i dati di test nel bucket.
Possibili cause:
-
L'account specificato per il proprietario del bucket del gruppo di report non corrisponde al proprietario del bucket Amazon S3.
-
Il ruolo di servizio non dispone dell'accesso in scrittura al bucket.
Soluzioni consigliate:
-
Modifica il proprietario del bucket del gruppo di report in modo che corrisponda al proprietario del bucket Amazon S3.
-
Modifica il ruolo del servizio per consentire l'accesso in scrittura al bucket Amazon S3.