You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I am running local CodeBuild container on my arm64 EC2 instance to validate buidspec.yml and build a simple Java application using maven, I noticed that the maven dependencies always get re-downloaded on each build instead of using my cache setting specified in buildspec.yml. I am only generating a zip file as an artefact (no container images built).
To Reproduce
Steps to reproduce the behavior:
Download official build image from AWS git repo
$ git clone https://github.com/aws/aws-codebuild-docker-images.git
$ cd aws-codebuild-docker-images
$ cd al2/aarch64/standard/3.0
$ docker build -t aws/codebuild/amzlinux2/arm64/standard/3.0 .
2 . Download ARM version of CodeBuild Agent
$ docker pull public.ecr.aws/codebuild/local-builds:aarch64
Expected behavior
I expected for CodeBuild to perform local host maven caching of downloaded artefacts. It re-downloads maven dependenies on each build as you can cleary see on output to console on all runs.
Logs
No indication of errors. Is this expected behaviour for local builds?
Here are my buildspec.yml contents (not the double star ** is not showing up in - '/root/.m2/**/*' but its there (just not shown in formated version of this file)...
version: 0.2
phases:
install:
runtime-versions:
java: corretto17
pre_build:
commands:
- echo Nothing to do in the pre_build phase...
build:
commands:
- echo Build started on date
- mvn install
post_build:
commands:
- echo Build completed on date
Platform (please complete the following information):
OS: Amazon Linux 2, arm64
ami id: ami-0dfa677c1b43a9673
ami name: amzn2-ami-kernel-5.10-hvm-2.0.20220316.0-arm64-gp2
Additional context
I tried performing a docker volume mount by modifying codebuild_build.sh to attempt to use my local directoryat $HOME/.m2 as the cache source once maven artifacts were downloaded in AWS CodeBuild container /root/.m2
I added thet volume mount line at position (line number 104 in .sh) but this had no effect.
...
if isOSWindows
then
docker_command+="-v //var/run/docker.sock:/var/run/docker.sock -e "
else
docker_command+="-v $HOME/.m2:/root/.m2 "
docker_command+="-v /var/run/docker.sock:/var/run/docker.sock -e "
fi
...
I also tried passing in "-d" option to codebuild_build.sh for privileged mode in case special persmission were needed but still nothing. Also logged into the conatiner via "docker run -it --entrypoint sh aws/codebuild/amzlinux2/arm64/standard/3.0 -c bash" command.
Noticed thet /root/.m2 was empty which surprised me. I then did a search for .jar files and found that they were mostly in
"opt/maven/lib and /root/.gradle
I ended up re-edited my buildspec.yml file and added those paths for cache as well but no changes (also for docker -v volume mounts)
The text was updated successfully, but these errors were encountered:
Describe the bug
I am running local CodeBuild container on my arm64 EC2 instance to validate buidspec.yml and build a simple Java application using maven, I noticed that the maven dependencies always get re-downloaded on each build instead of using my cache setting specified in buildspec.yml. I am only generating a zip file as an artefact (no container images built).
To Reproduce
Steps to reproduce the behavior:
$ git clone https://github.com/aws/aws-codebuild-docker-images.git
$ cd aws-codebuild-docker-images
$ cd al2/aarch64/standard/3.0
$ docker build -t aws/codebuild/amzlinux2/arm64/standard/3.0 .
2 . Download ARM version of CodeBuild Agent
$ docker pull public.ecr.aws/codebuild/local-builds:aarch64
$ curl -O https://raw.githubusercontent.com/aws/aws-codebuild-docker-images/master/local_builds/codebuild_build.sh
$ chmod +x codebuild_build.sh
$ ./codebuild_build.sh -i aws/codebuild/amzlinux2/arm64/standard/3.0 -a /tmp/codebuild_local -l public.ecr.aws/codebuild/local-builds:aarch64
Expected behavior
I expected for CodeBuild to perform local host maven caching of downloaded artefacts. It re-downloads maven dependenies on each build as you can cleary see on output to console on all runs.
Logs
No indication of errors. Is this expected behaviour for local builds?
Here are my buildspec.yml contents (not the double star ** is not showing up in - '/root/.m2/**/*' but its there (just not shown in formated version of this file)...
version: 0.2
phases:
install:
runtime-versions:
java: corretto17
pre_build:
commands:
- echo Nothing to do in the pre_build phase...
build:
commands:
- echo Build started on
date
- mvn install
post_build:
commands:
- echo Build completed on
date
reports:
springboot-junit-iterations-demo-reports:
files:
- '/*'
base-directory: 'target/surefire-reports'
discard-paths: no
file-format: JUNITXML
artifacts:
files:
- target/java-all-ways-to-iterate-0.0.1-SNAPSHOT.jar
cache:
paths:
- '/root/.m2//*'
Platform (please complete the following information):
Additional context
I tried performing a docker volume mount by modifying codebuild_build.sh to attempt to use my local directoryat $HOME/.m2 as the cache source once maven artifacts were downloaded in AWS CodeBuild container /root/.m2
I added thet volume mount line at position (line number 104 in .sh) but this had no effect.
...
if isOSWindows
then
docker_command+="-v //var/run/docker.sock:/var/run/docker.sock -e "
else
docker_command+="-v $HOME/.m2:/root/.m2 "
docker_command+="-v /var/run/docker.sock:/var/run/docker.sock -e "
fi
...
I also tried passing in "-d" option to codebuild_build.sh for privileged mode in case special persmission were needed but still nothing. Also logged into the conatiner via "docker run -it --entrypoint sh aws/codebuild/amzlinux2/arm64/standard/3.0 -c bash" command.
Noticed thet /root/.m2 was empty which surprised me. I then did a search for .jar files and found that they were mostly in
"opt/maven/lib and /root/.gradle
I ended up re-edited my buildspec.yml file and added those paths for cache as well but no changes (also for docker -v volume mounts)
The text was updated successfully, but these errors were encountered: