You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 8, 2020. It is now read-only.
We've encountered an interesting issue while deploying one of our stacks.
I can't go into specifics of the configuration for obvious reasons but I'll try to explain the best I can.
We are trying to deploy a aws_api_gateway_rest_api resource. We are using the template file data source. We have the file (a openapi.yaml file) and just render it to be used as the api body.
We didn't experience any issues up until now when there were some changes done to the openapi file.
The openapi file is now about 3500 lines big and is causing the panic. We tested that this is the issue using a smaller openapi file and it worked fine.
I would like to as if there is any limitation to this we should take into account going forward.
I was redirected here from the terragrunt github repo after submitting this issue to them.
We did some debugging and think that the issue is from the template provider.
We were able to deploy with a smaller rendered file.
Error we get:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xd37d71]
Hello,
We've encountered an interesting issue while deploying one of our stacks.
I can't go into specifics of the configuration for obvious reasons but I'll try to explain the best I can.
We are trying to deploy a aws_api_gateway_rest_api resource. We are using the template file data source. We have the file (a openapi.yaml file) and just render it to be used as the api body.
We didn't experience any issues up until now when there were some changes done to the openapi file.
The openapi file is now about 3500 lines big and is causing the panic. We tested that this is the issue using a smaller openapi file and it worked fine.
I would like to as if there is any limitation to this we should take into account going forward.
I was redirected here from the terragrunt github repo after submitting this issue to them.
We did some debugging and think that the issue is from the template provider.
We were able to deploy with a smaller rendered file.
Error we get:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xd37d71]
goroutine 53 [running]:
github.com/gruntwork-io/terragrunt/cli.runTerraformWithRetry(0xc0000db600, 0xc0000db600, 0xc0002f8900)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:531 +0x121
github.com/gruntwork-io/terragrunt/cli.runTerragruntWithConfig.func1(0x0, 0x0)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:484 +0x2a
github.com/gruntwork-io/terragrunt/cli.runActionWithHooks(0xf9a250, 0x9, 0xc0000db600, 0xc0002a8140, 0xc00043bc20, 0xc0004ee500, 0xc00060a140)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:495 +0x2ae
github.com/gruntwork-io/terragrunt/cli.runTerragruntWithConfig(0xc0000db600, 0xc0002a8140, 0x0, 0x0, 0x0)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:483 +0x2c7
github.com/gruntwork-io/terragrunt/cli.RunTerragrunt(0xc0000db600, 0xfa49a3, 0x15)
/go/src/github.com/gruntwork-io/terragrunt/cli/cli_app.go:370 +0x79c
github.com/gruntwork-io/terragrunt/configstack.(*runningModule).runNow(0xc0005c7c20, 0x0, 0x0)
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:238 +0x17a
github.com/gruntwork-io/terragrunt/configstack.(*runningModule).runModuleWhenReady(0xc0005c7c20)
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:201 +0x6a
github.com/gruntwork-io/terragrunt/configstack.runModules.func1(0xc00009f150, 0xc0005c7c20)
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:171 +0x51
created by github.com/gruntwork-io/terragrunt/configstack.runModules
/go/src/github.com/gruntwork-io/terragrunt/configstack/running_module.go:169 +0xe1
Makefile:68: recipe for target 'apply' failed
make: *** [apply] Error 2
The text was updated successfully, but these errors were encountered: