Closed Krenair closed 4 years ago
I have resorted to building support for the provider into the resource image:
FROM golang:1.14 as builder
WORKDIR /workspace
ENV CGO_ENABLED="0"
RUN git clone https://github.com/atlassian/terraform-provider-artifactory.git \
&& cd terraform-provider-artifactory \
&& go build
# Terraform 0.12.22
FROM ljfranklin/terraform-resource@sha256:d63ba8bb3262392adfa3e68dad9b94584bcb4ec74095392f51a3a71543afa33a
COPY --from=builder /workspace/terraform-provider-artifactory/terraform-provider-artifactory /usr/local/bin/terraform-provider-artifactory
@Krenair I have a test here which exercises the custom plugin flow. I just updated that test to use the new backend syntax and it seems to be working as expected.
I remember Terraform being very picky about the directory and file names in the plugin directory. Was your filename exactly terraform.d/plugins/linux_amd64/terraform-provider-artifactory_v1.6.3
? To further debug the issue I would try replicating your setup locally and use terraform init --plugin-dir your-plugin-dir
to figure out whether Terraform is able to recognize your plugins correctly.
No, the file's name was terraform.d/plugins/linux_amd64/terraform-provider-artifactory - but in any case, this was inside my terraform_source directory, how would a concourse get (which doesn't have a parameter to tell it where to find the source) be able to find that?
On Sat, 7 Mar 2020, 12:56 Lyle Franklin, notifications@github.com wrote:
@Krenair https://github.com/Krenair I have a test here https://github.com/ljfranklin/terraform-resource/blob/39f3825b2713ab4f63382967699674275ca5c72c/src/terraform-resource/out/out_custom_plugins_test.go#L234 which exercises the custom plugin flow. I just updated that test to use the new backend syntax and it seems to be working as expected.
I remember Terraform being very picky about the directory and file names in the plugin directory. Was your filename exactly terraform.d/plugins/linux_amd64/terraform-provider-artifactory_v1.6.3? To further debug the issue I would try replicating your setup locally and use terraform init --plugin-dir your-plugin-dir to figure out whether Terraform is able to recognize your plugins correctly.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ljfranklin/terraform-resource/issues/107?email_source=notifications&email_token=AAGJ2JQPLWNXKVRFFQZFYELRGI77DA5CNFSM4LC6S6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODYWOQ#issuecomment-596085562, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGJ2JX6GEOTYGWCQZ5OCH3RGI77DANCNFSM4LC6S6UQ .
@Krenair oh, I missed the part about this being on the get
step. I didn't realize Terraform had this behavior, but it looks when you run terraform init
with backends it also tries to look up plugins to download from the default
workspace. So I'm guessing at some point you've ran an apply
against the default
workspace and Terraform is trying to be overly helpful by downloading the artifactory plugin that the default
workspace uses.
I'll do some thinking about how to fix this going forward. In the meantime you can work around the issue by baking the plugin into a custom docker image as you've done or by deleting or moving the statefile out of the default
workspace.
I think the fix for the resource will be to add -get-plugins=false
to the init
call for the get
and check
steps. This wouldn't work if you had a backend that was declared in a plugin, but it looks like support for plugable backends isn't happening soon so I'm fine with this fix for now.
Yeah that sounds okay, alternatively we could make it possible to provide a source directory for plugins when getting?
On Sat, 7 Mar 2020, 14:30 Lyle Franklin, notifications@github.com wrote:
I think the fix for the resource will be to add -get-plugins=false to the init call for the get and check steps. This wouldn't work if you had a backend that was declared in a plugin, but it looks like support for plugable backends https://github.com/hashicorp/terraform/issues/5877 isn't happening soon so I'm fine with this fix for now.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ljfranklin/terraform-resource/issues/107?email_source=notifications&email_token=AAGJ2JQR4VJQ4MUOVLFFRQTRGJLARA5CNFSM4LC6S6U2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOD2ZVI#issuecomment-596094165, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGJ2JRIKXRJVUGGMQI46O3RGJLARANCNFSM4LC6S6UQ .
Afraid not, the Concourse design doesn't allow get
steps to receive any directories as input: https://concourse-ci.org/implementing-resource-types.html#resource-in
@Krenair I think this change should fix the issue you were having. That commit is now present on the ljfranklin/terraform-resource:latest
and ljfranklin/terraform-resource:0.12.23
images, when you get a chance can you check if that fixes the error you were seeing?
Seems to have done the trick, thanks.
Hi,
I was trying to use this with https://github.com/atlassian/terraform-provider-artifactory/ - I built it myself and placed it in a directory under my
terraform_source
dir calledterraform.d/plugins/linux_amd64
I'm using the S3 backend with arole_arn
I was able to plan/apply with the terraform-resource, but it fails at the implicit get stage when trying toterraform init
:This can't work as it won't have my terraform_source with the provider binary.