Open davidjb opened 1 year ago
Thanks for reporting. I was able to reproduce this and we welcome contributions if you'd like to help fix this issue!
@davidjb , the steps you mentioned as a workaround does not work on my side. My findings is SAM CLI does not write to build.toml
file even if exist in case if SAM CLI was invoked to build specific resources:
I will check with the team if this was done on purpose.
I checked this issue with the team, and we confirmed that SAM CLI does not create the build.toml
file when ASM CLI build specific resources, because we do not create the build graph in this case, and so we will not be able to create the build.toml
file.
The work around for this issue now is to first run sam build --cached
which will create the build.toml
file, and then the subsequent sam build --cached <<specific resource>>
commands executions will check the cached build of this resource, and skipped it if it is already cached.
@moelasmar So the issue is trying to reach a point where a sam build --cached
can succeed in the first place, especially given other issues such as https://github.com/aws/aws-sam-cli/issues/5280. More specifically, a situation where certain resources need to be built in containers and others cannot currently be built in containers, meaning it's effectively impossible without hacks and workarounds for certain setups.
It may be possible to change configurations and hack things up until sam build
yields an entry in build.toml
, but I'm thinking that a more reliable workaround is to generate a fake resource entry into build.toml
, such as:
[layer_build_definitions.00000000-0000-0000-0000-000000000000]
layer_name = "MyLayer"
codeuri = "/path/to/layers/mylayer"
build_method = "makefile"
compatible_runtimes = ["provided.al2"]
architecture = "arm64"
source_hash = "fake"
manifest_hash = ""
layer = "MyLayer"
Once this exists, then running sam build --cached <<specific resource>>
updates source_hash
correctly after that. Provided the UUID is any fake value, this appears to work.
Could a similar strategy be added into sam
itself? For a LayerVersion
in particular, there are no dependencies or build graphs, just that resource itself, so outputting the layer's config alone would be sufficient to solve this problem.
Description:
Starting with an empty environment (e.g. no
.aws-sam
directory or no.aws-sam/build.toml
file), attempting to build a layer by itself:does not result in the layer's build results being written to
.aws-sam/build.toml
. In fact, this file does not even get created.This means that subsequent calls to the same build command will not use the cache, despite cached files being created in
.aws-sam/cache
and that a problem such as #5507 cannot be worked around.Edit: currently, a Layer build will only update its entry within
.aws-sam/build.toml
(e.g. SAM won't create this file just for building a Layer), essentially meaning that in order for a Layer to be cached, it must first at least have been attempted to be cached. A workaround for this situation is to force the creation of.aws-sam/build.toml
, building in whatever way is necessary to generate the Layer's entry in this file (or otherwise manually creating the TOML would work too). In my case, it was quickest to just do:Steps to reproduce:
Remove any
.aws-sam
directory or.aws-sam/build.toml
fileDefine a Layer and Function such as this in
template.yaml
:Build that layer with:
sam build --cached --use-container MyLayer
Observe that no
.aws-sam/build.toml
file is created.Try and re-run
sam build
command and layer will not have been cached.Observed result:
Expected result:
Layer to be cached and recorded, available for subsequent runs of
sam build
.Additional environment details (Ex: Windows, Mac, Amazon Linux etc)