Explicitly set source_code_hash when using local_existing_package
nwalters512 opened this issue · 5 comments
Is your request related to a problem? Please describe.
I'm currently building my Lambda's source code on my own via a null_resource
(not using the source_path
attribute). I'm using local_existing_package
to point to that archive. However, I'm unable to deploy changes to the Lambda in a single pass, as I can't make the Lambda resource dependent on the archive_file
data source I use to create the archive.
Describe the solution you'd like.
I'd like to be able to explicitly pass source_code_hash
for my archive file.
Describe alternatives you've considered.
I saw #124, which was closed as implemented by #175. However, I can't tell how that PR actually fixed the issue. That's fine if I want to deploy my Lambda archives outside of Terraform, but I want to keep everything under Terraform's control.
Additional context
It would be nice to just use source_path
to configure a build, but I experienced frequent diffs even though I hadn't touched the source code. I believe this is because source_path
just isn't flexible enough to handle my specific use case (a Yarn monorepo that uses esbuild to build Lambda packages).
I don't think adding variable for source_code_hash
explicitly will be a good idea because:
-
I think you can specify
depends_on
in the module block to tell terraform to wait for the creation of the archive. -
You can also add
ignore_source_code_hash = true
(described in #175). -
Also, dealing with monorepos or other very dynamic codebases (e.g. terragrunt) is possible using this module. The trick is to figure out what files you want to exclude from the package using
patterns
(see this example, previous issues in this repository, and https://github.com/terraform-aws-modules/terraform-aws-lambda#combine-various-options-for-extreme-flexibility for more information).
Thank you for your quick response!
depends_on
doesn't seem to have the desired behavior. When I add e.g.depends_on = [ data.archive_file.my_archive_file ]
and then change something upstream of the archive file, the plan only produces a diff for theaws_iam_policy
andaws_iam_role
resources created by this module; there's no indication that the plan will update the lambda itself. Based on the docs at https://developer.hashicorp.com/terraform/language/meta-arguments/depends_on, I don't think it's surprising that this works incorrectly. The value of the hash is only known after apply, not during plan, and so Terraform isn't able to know that the hash has changed or will change until it's too late. By asking to explicitly setsource_code_hash
based on thebase64sha265
output of thearchive_file
, I'm trying to follow the recommendation of Terraform:
Instead of depends_on, we recommend using expression references to imply dependencies when possible. Expression references let Terraform understand which value the reference derives from and avoid planning changes if that particular value hasn’t changed, even if other parts of the upstream object have planned changes.
- As I mentioned in my original post, I don't see how
ignore_source_code_hash = true
would help me here. I want the source code hash to trigger an update to the lambda's code; I don't want to ignore it. - I don't think that
patterns
is flexible enough for my use case. To dig into the specifics: I want to useyarn.lock
,packages/my-package/package.json
, and the contents of apackages/my-package/src
directory as the inputs into the "hash", as I think this module calls it. If that hash changes, I want to runyarn build
inpackages/my-package
, and then use the contents ofpackages/my-package/dist
as the Lambda zip.patterns
seems to be used for both "rebuild when these patterns change" and "include these files in the zip", but I want to use separate patterns for each of them, and as far as I can tell there's no way to do that.
This issue has been automatically marked as stale because it has been open 30 days
with no activity. Remove stale label or comment or this issue will be closed in 10 days
This issue was automatically closed because of stale in 10 days