View a markdown version of this page

Troubleshooting AWS CodeBuild - AWS CodeBuild
Apache Maven builds reference artifacts from the wrong repositoryBuild commands run as root by defaultBuilds might fail when file names have non-U.S. English charactersBuilds might fail when getting parameters from Amazon EC2 Parameter StoreCannot access branch filter in the CodeBuild consoleCannot view build success or failureBuild status not reported to source providerCannot find and select the base image of the Windows Server Core 2019 platformEarlier commands in buildspec files are not recognized by later commandsError: "Access denied" when attempting to download cacheError: "BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE" when using a custom build imageError: "Build container found dead before completing the build. build container died because it was out of memory, or the Docker image is not supported. ErrorCode: 500"Error: "Cannot connect to the Docker daemon" when running a buildError: "CodeBuild is not authorized to perform: sts:AssumeRole" when creating or updating a build projectError: "Error calling GetBucketAcl: Either the bucket owner has changed or the service role no longer has permission to called s3:GetBucketAcl"Error: "Failed to upload artifacts: Invalid arn" when running a buildError: "Git clone failed: Unable to access 'your-repository-URL': SSL certificate problem: Self signed certificate"Error: "The bucket you are attempting to access must be addressed using the specified endpoint" when running a buildError: "This build image requires selecting at least one runtime version."Error: "QUEUED: INSUFFICIENT_SUBNET" when a build in a build queue failsError: "Unable to download cache: RequestError: Send request failed caused by: x509: Failed to load system roots and no roots provided"Error: "Unable to download certificate from S3. AccessDenied"Error: "Unable to locate credentials"RequestError timeout error when running CodeBuild in a proxy serverThe bourne shell (sh) must exist in build imagesWarning: "Skipping install of runtimes. runtime version selection is not supported by this build image" when running a buildError: "Unable to verify JobWorker identity"Build failed to startAccessing GitHub metadata in locally cached buildsAccessDenied: The bucket owner for the report group does not match the owner of the S3 bucket...Error: "Your credentials lack one or more required privilege scopes" when creating a CodeBuild project with CodeConnectionsError: "Sorry, no terminal at all requested - can't get input" when building with the Ubuntu install commandBitbucket builds fail with authentication errors after using Secrets Manager OAuth

Troubleshooting AWS CodeBuild

Use the information in this topic to help you identify, diagnose, and address issues. To learn how to log and monitor CodeBuild builds to troubleshoot issues, see Logging and monitoring.

Topics

Apache Maven builds reference artifacts from the wrong repository

Issue: When you use Maven with an AWS CodeBuild-provided Java build environment, Maven pulls build and plugin dependencies from the secure central Maven repository at https://repo1.maven.org/maven2. This happens even if your build project's pom.xml file explicitly declares other locations to use instead.

Possible cause: CodeBuild-provided Java build environments include a file named settings.xml that is preinstalled in the build environment's /root/.m2 directory. This settings.xml file contains the following declarations, which instruct Maven to always pull build and plugin dependencies from the secure central Maven repository at 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>

Recommended solution: Do the following:

  1. Add a settings.xml file to your source code.

  2. In this settings.xml file, use the preceding settings.xml format as a guide to declare the repositories you want Maven to pull the build and plugin dependencies from instead.

  3. In the install phase of your build project, instruct CodeBuild to copy your settings.xml file to the build environment's /root/.m2 directory. For example, consider the following snippet from a buildspec.yml file that demonstrates this behavior.

    version 0.2 phases: install: commands: - cp ./settings.xml /root/.m2/settings.xml

Build commands run as root by default

Issue: AWS CodeBuild runs your build commands as the root user. This happens even if your related build image's Dockerfile sets the USER instruction to a different user.

Cause: By default, CodeBuild runs all build commands as the root user.

Recommended solution: None.

Builds might fail when file names have non-U.S. English characters

Issue: When you run a build that uses files with file names that contain non-U.S. English characters (for example, Chinese characters), the build fails.

Possible cause: Build environments provided by AWS CodeBuild have their default locale set to POSIX. POSIX localization settings are less compatible with CodeBuild and file names that contain non-U.S. English characters and can cause related builds to fail.

Recommended solution: Add the following commands to the pre_build section of your buildspec file. These commands make the build environment use U.S. English UTF-8 for its localization settings, which is more compatible with CodeBuild and file names that contain non-U.S. English characters.

For build environments based on Ubuntu:

pre_build: commands: - export LC_ALL="en_US.UTF-8" - locale-gen en_US en_US.UTF-8 - dpkg-reconfigure -f noninteractive locales

For build environments based on Amazon Linux:

pre_build: commands: - export LC_ALL="en_US.utf8"

Builds might fail when getting parameters from Amazon EC2 Parameter Store

Issue: When a build tries to get the value of one or more parameters stored in Amazon EC2 Parameter Store, the build fails in the DOWNLOAD_SOURCE phase with the error Parameter does not exist.

Possible cause: The service role the build project relies on does not have permission to call the ssm:GetParameters action or the build project uses a service role that is generated by AWS CodeBuild and allows calling the ssm:GetParameters action, but the parameters have names that do not start with /CodeBuild/.

Recommended solutions:

  • If the service role was not generated by CodeBuild, update its definition to allow CodeBuild to call the ssm:GetParameters action. For example, the following policy statement allows calling the ssm:GetParameters action to get parameters with names starting with /CodeBuild/:

    JSON
    { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/CodeBuild/*" } ] }
  • If the service role was generated by CodeBuild, update its definition to allow CodeBuild to access parameters in Amazon EC2 Parameter Store with names other than those starting with /CodeBuild/. For example, the following policy statement allows calling the ssm:GetParameters action to get parameters with the specified name:

    JSON
    { "Version":"2012-10-17", "Statement": [ { "Action": "ssm:GetParameters", "Effect": "Allow", "Resource": "arn:aws:ssm:us-east-1:111122223333:parameter/PARAMETER_NAME" } ] }

Cannot access branch filter in the CodeBuild console

Issue: The branch filter option is not available in the console when you create or update an AWS CodeBuild project.

Possible cause: The branch filter option is deprecated. It has been replaced by webhook filter groups, which provide more control over the webhook events that trigger a new build in CodeBuild.

Recommended solution: To migrate a branch filter that you created before the introduction of webhook filters, create a webhook filter group with a HEAD_REF filter with the regular expression ^refs/heads/branchName$. For example, if your branch filter regular expression was ^branchName$, then the updated regular expression you put in the HEAD_REF filter is ^refs/heads/branchName$. For more information, see Bitbucket webhook events and Filter GitHub webhook events (console).

Cannot view build success or failure

Issue: You cannot see the success or failure of a retried build.

Possible cause: The option to report your build's status is not enabled.

Recommended solutions: Enable Report build status when you create or update a CodeBuild project. This option tells CodeBuild to report back the status when you trigger a build. For more information, see reportBuildStatus in the AWS CodeBuild API Reference.

Build status not reported to source provider

Issue: After allowing build status reporting to a source provider, such as GitHub or Bitbucket, the build status is not updated.

Possible cause: The user associated with the source provider does not have write access to the repo.

Recommended solutions: To be able to report the build status to the source provider, the user associated with the source provider must have write access to the repo. If the user does not have write access, the build status cannot be updated. For more information, see Source provider access.

Cannot find and select the base image of the Windows Server Core 2019 platform

Issue: You cannot find or select the base image of the Windows Server Core 2019 platform.

Possible cause: You are using an AWS Region that does not support this image.

Recommended solutions: Use one of the following AWS Regions where the base image of the Windows Server Core 2019 platform is supported:

  • US East (N. Virginia)

  • US East (Ohio)

  • US West (Oregon)

  • Europe (Ireland)

Earlier commands in buildspec files are not recognized by later commands

Issue: The results of one or more commands in your buildspec file are not recognized by later commands in the same buildspec file. For example, a command might set a local environment variable, but a command run later might fail to get the value of that local environment variable.

Possible cause: In buildspec file version 0.1, AWS CodeBuild runs each command in a separate instance of the default shell in the build environment. This means that each command runs in isolation from all other commands. By default, then, you cannot run a single command that relies on the state of any previous commands.

Recommended solutions: We recommend that you use buildspec version 0.2, which solves this issue. If you must use buildspec version 0.1, we recommend that you use the shell command chaining operator (for example, && in Linux) to combine multiple commands into a single command. Or include a shell script in your source code that contains multiple commands, and then call that shell script from a single command in the buildspec file. For more information, see Shells and commands in build environments and Environment variables in build environments.

Error: "Access denied" when attempting to download cache

Issue: When attempting to download the cache on a build project that has cache enabled, you receive an Access denied error.

Possible causes:

  • You have just configured caching as part of your build project.

  • The cache has recently been invalidated through the InvalidateProjectCache API.

  • The service role being used by CodeBuild does not have s3:GetObject and s3:PutObject permissions to the S3 bucket that is holding the cache.

Recommended solution: For first time use, it's normal to see this immediately after updating the cache configuration. If this error persists, then you should check to see if your service role has s3:GetObject and s3:PutObject permissions to the S3 bucket that is holding the cache. For more information, see Specifying S3 permissions in the Amazon S3 Developer Guide.

Error: "BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE" when using a custom build image

Issue: When you try to run a build that uses a custom build image, the build fails with the error BUILD_CONTAINER_UNABLE_TO_PULL_IMAGE.

Possible cause: The build image's overall uncompressed size is larger than the build environment compute type's available disk space. To check your build image's size, use Docker to run the docker images REPOSITORY:TAG command. For a list of available disk space by compute type, see Build environment compute modes and types.

Recommended solution: Use a larger compute type with more available disk space, or reduce the size of your custom build image.

Possible cause: AWS CodeBuild does not have permission to pull the build image from your Amazon Elastic Container Registry (Amazon ECR).

Recommended solution: Update the permissions in your repository in Amazon ECR so that CodeBuild can pull your custom build image into the build environment. For more information, see the Amazon ECR sample.

Possible cause: The Amazon ECR image you requested is not available in the AWS Region that your AWS account is using.

Recommended solution: Use an Amazon ECR image that is in the same AWS Region as the one your AWS account is using.

Possible cause: You are using a private registry in a VPC that does not have public internet access. CodeBuild cannot pull an image from a private IP address in a VPC. For more information, see Private registry with AWS Secrets Manager sample for CodeBuild.

Recommended solution: If you use a private registry in a VPC, make sure the VPC has public internet access.

Possible cause: If the error message contains "toomanyrequests", and the image is obtained from Docker Hub, this error means the Docker Hub pull limit has been reached.