0.5.2 fails during terraform plan when running in alpine-based Docker image
Closed this issue · 5 comments
When using the 0.5.2 binary, terraform planfails with the following error:
Error: Failed to instantiate provider "auth0" to obtain schema: fork/exec /home/username/.terraform.d/plugins/linux_amd64/terraform-provider-auth0_v0.5.2: no such file or directory
The Docker image used is based on the latest 'alpine' image from DockerHub, currently version 3.11.3. Terraform version is 0.12.19.
The binary is correctly named according to the provider conventions, and the Terraform logs from the terraform init stage confirm that it can be loaded:
2020/02/27 15:31:26 [DEBUG] found valid plugin: "auth0", "0.5.2", "/home/username/.terraform.d/plugins/linux_amd64/terraform-provider-auth0_v0.5.2"
At first glance, this would appear to be extremely similar to this issue with another provider: Mastercard/terraform-provider-restapi#65. See also runatlantis/atlantis#690 and https://medium.com/@laiello/cgo-with-custom-terraform-providers-65135604fa8c. Is CGO_ENABLED=0 set during the plugin build?
It's also worth noting that this didn't seem to be an issue with 0.5.1; I've tested with alpine versions back to 3.7, and the issue only occurs with 0.5.2.
Hi @garry-jeromson, might it be related to the tag being a release candidate? I've published 0.5.2 today, so you might prefer to try it.
Hey @alexkappa, thanks for the suggestion - the issue also occurs with both 0.5.2-rc.1 and 0.5.2.
It'd be excellent if we could set CGO_ENABLED=0 in the release workflow to fix the issue - I'll put together a pull request.
Hmmm, just saw that CGO_ENABLED=0 is already set in .goreleaser.yaml (thanks for nothing, GitHub search function).
Are the current release binaries built using Travis or GitHub workflows?
After some tests with local builds, I confirm that setting CGO_ENABLED=0 before running a build results in a working version of 0.5.2 within an alpine-based Docker container, and that not setting it results in the aforementioned error. It would seem then, that this isn't being set for the release builds.
This issue is stale because it has been open 30 days with no activity.
Stale issues will be closed after 5 days if no action is taken. If you
think this issue should not be closed, remove the stale label.