-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FAIL: TestProvider: id is a reserved field name for a resource with latests github.com/hashicorp/terraform #353
Comments
This doesn't seem to be happening with the vendored version of hashicorp/terraform in https://github.com/terraform-providers/terraform-provider-google/tree/master/vendor/github.com/hashicorp/terraform |
Looks like the warning code was introduced here: hashicorp/terraform#15522 |
This appears to have been introduced into this repo in #302. Weirdly, this seems to pass in our CI? It also passes for me locally. Can you let us know what revision you're building under and what command you're using, @cthiel? That aside, those resources are subtly broke at the moment until those things are fixed. I think, for some resources, the breakage isn't really material, but for others it may make a difference. From my understanding, resources that have an |
I'm building against hashicorp/terraform master as of last week, ie not using the vendored version (at all). You should be able to update the vendored version using govendor and switch to master instead of the 0.10.0 tag. (Sorry I don't have commands ready to reproduce this easily.) |
So you're explicitly ignoring the vendored version? Can I ask how, and why? The main reason I ask is I seem to be unable to reproduce this. [EDIT] Looks like |
This is mostly due to the fact that the build system that I'm using is discouraging vendored dependencies. Also, it seems risky to have terraform-providers/terraform-provider-google vendor much and then diverge from master, which then later requires more work to be done to re-base and integrate, like this bug is showing. (I'm happy to explain in more detail via mail.) |
Hey @cthiel, thanks for the clarification. While this specific instance is something we're definitely interested in fixing, as it represents code that's broken in the vendored directory, I just want to be clear that we explicitly do not track master of all the dependencies, and builds that don't use our pinned, vendored dependencies are likely to fail, possibly in destructive and surprising ways. They're explicitly not supported. As for diverging, we don't really ever diverge from any of our dependencies, that I know of. But we do lag. We have so many providers, each with so many dependencies, that keeping all of them working against master all the time is an unrealistic goal. So we update dependencies as they get bug fixes and improvements that are used in the provider, making the changes necessary at that time. That being said, because this specific change doesn't introduce the break, it just exposes it, I'm definitely interested in getting these resources updated to work correctly. |
Sure, thanks for the clarifications and looking into fixing the provider! |
This certainly shouldn't be happening. The intention of the extra check I introduced a while back was only to force providers to clean up the schema by removing fields which have no effect, Based on ^ that the ID should always be set in the state, if |
@radeksimko this is my understanding based on hashicorp/terraform#10425 (comment) Basically, your check didn't break things, just exposed things that were already broken. So even though But the upshot of this is that we're using a reserved name as a field, we shouldn't be, and the new check doesn't break code, it just tells us code we broke long ago is broken. :) I'll open PRs to migrate off |
All uses of |
…shicorp#353) <!-- This change is generated by MagicModules. --> /cc @rileykarson
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks! |
I'm building & testing terraform-provider-google with the latests github.com/hashicorp/terraform and ran into this test failure:
Just removing the id entries from the schema for the respective resources fixes the tests, but I'm unsure about the side-effects this might cause.
The text was updated successfully, but these errors were encountered: