unable to find builds when first building (second time works) #204
Comments
|
Please make sure that you are using v2.16.0 of this module or newer. See CHANGELOG. The problem you are experiencing has been fixed by #181 Here you can see a bit more info that can help you to make it to work in CI/CD pipeline - https://github.com/terraform-aws-modules/terraform-aws-lambda#lambda-function-or-lambda-layer-with-the-deployable-artifact-maintained-separately-from-the-infrastructure |
|
Sorry, i should have mentioned, i am using version 2.18.0 of this module and still hitting this error. |
|
Ok, show the complete |
|
Here it is: After upgrading i also deleted .terraform and builds, and ran init again. |
|
I can't reproduce it. Here is how I do it. I have module "lambda_webhook_disabler" {
source = "terraform-aws-modules/lambda/aws"
version = "2.18.0"
function_name = "webhook_disabler"
handler = "webhook_disabler.main"
runtime = "python3.8"
timeout = 300
publish = true
# source path is relative and pointing to this directory locally:
# https://github.com/terraform-aws-modules/terraform-aws-lambda/tree/master/examples/fixtures/python3.8-app1
source_path = "../../terraform-aws-lambda/examples/fixtures/python3.8-app1"
}
All good and as expected. Now, if I remove The plan and zip archives are being recreated locally. If I specify I am not sure what else can we do here. |
|
I got same issue. |
|
I'm also seeing this behaviour when running an apply against a fresh clone of a repository. |
|
using version 2.25.0 and getting the same issue. Is there any workaround at all? |
|
Same here with 2.28.0, I had to apply twice... |
|
This issue occurs when two Lambda functions are attempting to use the same Specifically, the archive plan uses the (identical) source hash as a file name for the zip file. When two functions are deployed, the packager(s) race (which is why it succeeds on a subsequent attempt). Reproducible example: terraform {
backend "local" {}
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 3.0"
}
}
}
module "lambda1" {
source = "terraform-aws-modules/lambda/aws"
version = "2.28.0"
function_name = "app1"
handler = "app1.lambda_handler"
runtime = "python3.9"
source_path = "${path.module}/src"
}
# Same src folder, different handler
module "lambda2" {
source = "terraform-aws-modules/lambda/aws"
version = "2.28.0"
function_name = "app2"
handler = "app2.lambda_handler"
runtime = "python3.9"
source_path = "${path.module}/src"
}An initial plan shows: And on apply: I worked around it by explicitly re-using the packaged artefact from one function in the other. This is already covered in #139. |
|
This issue has been automatically marked as stale because it has been open 30 days |
|
This issue was automatically closed because of stale in 10 days |
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
On every first "build" of any of my python 3.8 lambdas i get the following error message:
each future build is successful until i delete
.terraformand thebuildsfolder.Before you submit an issue, please perform the following first:
.terraformdirectory (! ONLY if state is stored remotely, which hopefully you are following that best practice!):rm -rf .terraform/terraform initVersions
Reproduction
Steps to reproduce the behavior:
No Yes remove local cache, have a python 3.8 lambda that needs to be packaged and deployed to LambdaExpected behavior
Successful run on the first run.
Actual behavior
Using this module to terraform apply always fails the first time after deleting .terraform and builds, but works on the second time.
This is hard because it makes building/deploying via github actions difficult since every time is the first run.
The text was updated successfully, but these errors were encountered: