Update Terraform cloudposse/lambda-function/aws to v0.5.3 (main) - autoclosed

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
cloudposse/lambda-function/aws (source)	module	minor	0.3.2 -> 0.5.3

---

Release Notes

cloudposse/terraform-aws-lambda-function (cloudposse/lambda-function/aws)

v0.5.3

Compare Source

fix: Allow for custom_iam_policy_arns that are unknown at apply @​natemccurdy (#​46)

what

Replace the toset() in the aws_iam_role_policy_attachment resource's for_each attribute with a map of name:ARN pairs.

why

Prior to this patch, specifying custom_iam_policy_arns for IAM Policies that do not exist yet and would be created in the same Terraform run that creates the Lambda Execution Role would cause the following error:

│ Error: Invalid for_each argument
│
│   on .terraform/modules/foo.test_lambda/iam-role.tf line 81, in resource "aws_iam_role_policy_attachment" "custom":
│   81:   for_each = local.enabled && length(var.custom_iam_policy_arns) > 0 ? var.custom_iam_policy_arns : toset([])
│     ├────────────────
│     │ local.enabled is true
│     │ var.custom_iam_policy_arns is set of string with 3 elements
│
│ The "for_each" set includes values derived from resource attributes that cannot be determined until apply, and so Terraform cannot determine the full set of keys that will identify the instances of this resource.
│
│ When working with unknown values in for_each, it's better to use a map value where the keys are defined statically in your configuration and where only the values contain apply-time results.
│
│ Alternatively, you could use the -target planning option to first apply only the resources that the for_each value depends on, and then apply a second time to fully converge.

This is due to the ARN's of those policies not being known at apply time and the usage of toset() in the aws_iam_role_policy_attachment resource's for_each parameter. As the set's values are unknown at apply time, Terraform can't create a dependency graph.

references

Similar issues with similar fixes in other CloudPosse modules:

• https://github.com/cloudposse/terraform-aws-s3-bucket/pull/202
• https://github.com/cloudposse/terraform-aws-ecs-alb-service-task/pull/194

🚀 Enhancements

fix: Add null/label context tags to the aws_lambda_function resource @​natemccurdy (#​44)

What

Use tags = module.this.tags on the aws_lambda_function resource.

Why

Prior to this, the aws_lambda_function resource was not getting tagged at all
when passing just the null/label context into the module.

For example, this would end up with a completely untagged Lambda function even
though I am passing the context from a standard null/label declaration:

module "test" {
  source  = "cloudposse/lambda-function/aws"
  version = "0.5.1"

  function_name = "${module.this.id}-test"
  attributes    = ["foo"]
  description   = var.lambda_description
  s3_bucket     = var.lambda_s3_bucket
  s3_key        = var.lambda_s3_key
  runtime       = var.lambda_runtime
  handler       = var.lambda_handler
  context       = module.this.context
}

To get any tags on the lambda, the tags attribute must be used:

module "test" {
  source  = "cloudposse/lambda-function/aws"
  version = "0.5.1"

  function_name = "${module.this.id}-test"
  attributes    = ["foo"]
  description   = var.lambda_description
  s3_bucket     = var.lambda_s3_bucket
  s3_key        = var.lambda_s3_key
  runtime       = var.lambda_runtime
  handler       = var.lambda_handler
  context       = module.this.context
  tags          = module.this.tags
}

This has a couple of problems:

1. The attributes list is missing from the resultant set of tags.
2. The requirement of passing an explicit tags attribute is not how other CloudPosse modules work.

Outcome

• The aws_lambda_function resource is tagged with the implicit tags passed in via context.
• Tags from the tags variable are still present, but are now merged with the tags from context.
• This module follows the convetion of other CloudPosse modules.
• People used to CloudPosse modules will have an easier time using this module.

v0.5.2

Compare Source

🚀 Enhancements

fix: Add context tags to the IAM resources @​natemccurdy (#​45)

what

Add tags = module.this.tags to each of the IAM resources so that they use the tags determined by the null/label context or the tags input.

why

Prior to this, the aws_iam_role and the aws_iam_policy created by this module did not include any of the tags passed via tags or via context.

v0.5.1

Compare Source

🚀 Enhancements

fix: addresses issues with lambda cloudwatch log group @​Gowiem (#​39)

what

• Updates CloudWatch log group name for required pattern

why

• AWS requires the log group pattern to be specific for Lambda to be able to log to it. From https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs:

You can insert logging statements into your code to help you validate that your code is working as expected. Lambda automatically integrates with CloudWatch Logs and pushes all logs from your code to a CloudWatch Logs group associated with a Lambda function, which is named /aws/lambda/.

references

• This is an update of #​34 as that was blocked from editing. Closes #​34

v0.5.0

Compare Source

Add ephemeral storage size option @​drselump14 (#​31)

What

• Adds an option to set ephemeral storage size via a new variable: ephemeral_storage_size
• Removes variables that were not used in the code:
  • event_source_mappings
  • ignore_external_function_updates
  • sns_subscriptions
  • cloudwatch_event_rules
  • cloudwatch_log_subscription_filters

Why

• Enables module consumers to set larger ephemeral disk space for their Lambdas
• Cleans up unused code.

Sync github @​max-lobur (#​37)

Rebuild github dir from the template

Fix link to examples in readme @​sindrig (#​25)

what

• Links to examples link to a non-existing page

v0.4.1

Compare Source

🚀 Enhancements

Update module versions, examples and tests @​aknysh (#​24)

what

• Update module versions, examples and tests
• Update README and LICENSE
• Fix TF code formatting

why

• Keep up to date

v0.4.0

Compare Source

ignore last_modified attribute @​codekitchen (#​23)

what

• ignore last_modified attribute of the aws_lambda_function resource

why

In the past I've used this module with a local filename without issue, but we just used it with a new lambda function whose code we are storing externally in S3 so using the s3_key/s3_bucket attributes, and on every terraform apply it wants to update the last_modified attribute e.g.:

Terraform will perform the following actions:
### module.xxx.aws_lambda_function.this[0] will be updated in-place
  ~ resource "aws_lambda_function" "this" {
        id                             = "xxx"
      ~ last_modified                  = "2022-07-05T22:43:11.813+0000" -> (known after apply)
        tags                           = {}
### (20 unchanged attributes hidden)
### (2 unchanged blocks hidden)
    }

Adding this lifecycle rule avoids this spurious update. I'm open to other suggestions though!

v0.3.6

Compare Source

🚀 Enhancements

patch: Fix lambda role logic @​jamengual (#​18)

what

• Fix logic in iam_role policy attachment.

why

• because is fails with :

│ 
│   on .terraform/modules/sample_lambda.lambda_function/iam-role.tf line 35, in resource "aws_iam_role_policy_attachment" "vpc_access":
│   35:   count = local.enabled && try(length(var.vpc_config), 0) > 0 ? 1 : 0
│ 
│ The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.```
</details>

v0.3.5

Compare Source

🚀 Enhancements

Always add lambda.amazonaws.com id @​nitrocode (#​17)

what

• Always add lambda.amazonaws.com id

why

• lambda@edge requires both edgelambda and lambda identifiers

references

• Closes https://github.com/cloudposse/terraform-aws-lambda-function/issues/14

v0.3.4

Compare Source

🚀 Enhancements

Attach VPC and XRay Roles when needed @​jamengual (#​16)

what

• Fix iam policy attachment logic

why

• when Xray to vpc_config is enabled the policy logic does not attach the proper managed policies.

references

• closes https://github.com/cloudposse/terraform-aws-lambda-function/issues/13
• closes https://github.com/cloudposse/terraform-aws-lambda-function/issues/10

v0.3.3

Compare Source

Added dead_letter_config @​3h4x (#​15)

what

• Added variable to configure DLQ

why

• To have DLQ in lambda

git.io->cloudposse.tools update @​dylanbannon (#​12)

what and why

Change all references to git.io/build-harness into cloudposse.tools/build-harness, since git.io redirects will stop working on April 29th, 2022.

References

• DEV-143

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.

[renovate]

Autoclosing Skipped

This PR has been flagged for autoclosing. However, it is being skipped due to the branch being already modified. Please close/delete it manually or report a bug if you think this is in error.