Explicitly set source_code_hash when using local_existing_package

[nwalters512]

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).

[antonbabenko]

I don't think adding variable for source_code_hash explicitly will be a good idea because:

1. I think you can specify depends_on in the module block to tell terraform to wait for the creation of the archive.

2. You can also add ignore_source_code_hash = true (described in #175).

3. 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).

[nwalters512]

Thank you for your quick response!

1. 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 the aws_iam_policy and aws_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 set source_code_hash based on the base64sha265 output of the archive_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.

2. 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.
3. I don't think that patterns is flexible enough for my use case. To dig into the specifics: I want to use yarn.lock, packages/my-package/package.json, and the contents of a packages/my-package/src directory as the inputs into the "hash", as I think this module calls it. If that hash changes, I want to run yarn build in packages/my-package, and then use the contents of packages/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.

[github-actions]

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

[github-actions]

This issue was automatically closed because of stale in 10 days