New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sam build cache does not seem to work with CodeBuild #2859
Comments
Possible cause: SAM CLI cannot recognize |
Update: On MacOS it works fine with symbolic links: $ mkdir tmp
$ mv .aws-sam tmp
$ ln -s tmp/.aws-sam .aws-sam
$ sam build # same build command as above
...
Same function build definition found, adding function... |
After looking around I'm inclined to think this is a CodeBuild issue. People are having all kinds of trouble getting CodeBuild caching to work:
|
the code directory (absolute path) is also part of what we use to check cache. Can you check whether [Edit] I think build cache should not use absolute path as part of ID, working on a fix |
You have a very good point, it looks like the |
I am facing the same issue and I found a stack overflow post discussing a similar issue. |
Did you find a workaround @mufumade? Seems like a fix is not coming any time soon. |
In the following vid he shows exactly that problem. The relevant part starts at minute 53. He builds a custom swift lambda runtime but he nicely shows how to handle the folder deletion of sam build. So you can apply that to whatever you are building.
Inodes get changed because of the changing container you get from codebuild every time you build something. I even tried to mount a efs to codebuild ( which worked but it is way to expensive because you need a nat gateway) and did all the building on that efs to counter the changing inodes and relative paths but no luck ( at least for me with swift build ) |
Thank you for the detailed explanation! I will try that and see if it works for my use case. |
Hi, I think I know what's happening here. Only adding the cache folder like below is not enough to validate the cache. cache: You should also include the build.toml file, which holds the hashes and what not to validate the cache, cache: Try it out and let me know. You shouldn't have to do any weird stuff to make sam caching work with codebuild cache. sam build --template sam.yaml --base-dir ./ --cached --parallel |
Interesting.. will try it out when I have time! Hopefully next week. |
@TheFlexican Are you talking about changing the sam source code or is there something in my project I can add that configuration to in order to see these improvements? |
You need to put it in your buildspec.yml. Here is an example. version: 0.2
phases:
install:
runtime-versions:
python: 3.9
commands:
- echo nothing to install
build:
commands:
- sam build --template sam.yaml --cached --parallel
- sam package ...
post_build:
commands:
- echo Build completed on `date`
artifacts:
type: zip
base-directory: ./
files:
- path/**/*
cache:
paths:
- .aws-sam/cache/**/*
- .aws-sam/build.toml |
All right, sorry for the long delay. According to the buildspec specification (https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html), the path I provided ( The problem is instead that without adding Adding Thanks for the help 🎉 |
Description:
Cache works locally on my computer (MacOS 11.3), but never in CodeBuild (aws/codebuild/amazonlinux2-x86_64-standard:3.0).
I have verified that the CodeBuild cache path is exactly the same for two subsequent builds, but
sam build
still says the cache is invalid.I think it might have something to do with paths or symlinks, but not sure.
Sorry if this is the wrong place to report this.
Steps to reproduce:
CodeBuild set to custom local cache (also tried with s3 cache, still does not work).
buildspec.yml (modified for brevity)
build.sh (modified for brevity)
Observed result:
CodeBuild mounts the cache path correctly (
<id>
is the cache id that I verified stays the same for subsequent builds):Expected result:
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
sam --version
: 1.22.0The text was updated successfully, but these errors were encountered: