Availability to disable timestamp for lambda package

[jBouyoud]

Is your request related to a new offering from AWS?

Is this functionality available in the AWS provider for Terraform? See CHANGELOG.md, too.

• No 🛑: please wait to file a request until the functionality is avaialble in the AWS provider
• Yes ✅: please list the AWS provider version which introduced this functionality

Is your request related to a problem? Please describe.

When using this module in a CI environment that aims to detect drift. If the package is freshly checkout the timestamp is always drifting even the checksum doesn't move.

Describe the solution you'd like.

Give a way to disable timestamp checks (probably with a terraform variable)

Describe alternatives you've considered.

Manually touch with a specific timestamp all file that are targeted by the module instance

Additional context

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # module.lambda-export-elasticache-exports.null_resource.archive[0] must be replaced
-/+ resource "null_resource" "archive" {
      ~ id       = "4346580655420454952" -> (known after apply)
      ~ triggers = { # forces replacement
          ~ "timestamp" = "1673343927935659800" -> "1673447867144085800"
            # (1 unchanged element hidden)
        }
    }

Plan: 1 to add, 0 to change, 1 to destroy.

[evya123]

Would be super helpful since currently every run detects a change :\

[andrewhharmon]

plus one for this, I thought maybe i was doing something wrong. Is there any workaround at the moment?

[andrewhharmon]

curious if this is caught anyone's attention. Does it really need to use the timestamp if it has the file hash?

[jussapaavo]

This does seem to be related to the issues #51, #63 and #323. We're also having this issue, but only when using Terrafrom with multiple envs (users and CI). When deploying from the same env we don't receive these changes with terraform plan.

We tried the suggested fix by using TF_RECREATE_MISSING_LAMBDA_PACKAGE=false env var, but it didn't work for us and instead these Terraform changes persisted when running from multiple envs.

[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

[msrdjan]

Setting recreate_missing_package module variable to false worked for me.

Module lambda.null_resource.archive[0] was updated once more, due to a change in the timestamp trigger ("1679200526172839000" change to "<WARNING: Missing lambda zip artifacts wouldn't be restored>"), but not in the following runs.

[nwalters512]

Does anyone understand the implications of the "Missing lambda zip artifacts wouldn't be restored" warning?

[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

[spectorar]

Bumping this issue. Just spent hours debugging a scenario. A terraform plan/apply partially failed in CI and subsequent builds continued to fail because the package wasn't being regenerated. We have to have recreate_missing_package set to false for CI purposes, however in the event that null_resource.archive hasn't changed while aws_lambda_function.this has (admittedly an edge case), nothing triggers the package to be generated. An option to ignore the timestamp for package comparison would allow recreate_missing_package to be set to true while not causing terraform to detect a change when their hasn't been one to the actual source code.

@nwalters512 This scenario my team managed to get ourselves into seems to be one such implication.

[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