-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Check example vars #13938
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
Check example vars #13938
Conversation
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Tests analyticsTotal tests: 1316 Click here to see the affected service packages
Action takenFound 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
|
🟢 Tests passed during RECORDING mode: 🟢 No issues found for passed tests after REPLAYING rerun. 🟢 All tests passed! |
Tests analyticsTotal tests: 1316 Click here to see the affected service packages
Action takenFound 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
|
🟢 Tests passed during RECORDING mode: 🟢 No issues found for passed tests after REPLAYING rerun. 🟢 All tests passed! |
Tests analyticsTotal tests: 1316 Click here to see the affected service packages
Action takenFound 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
|
🟢 Tests passed during RECORDING mode: 🟢 No issues found for passed tests after REPLAYING rerun. 🟢 All tests passed! |
Tests analyticsTotal tests: 1316 Click here to see the affected service packages
Action takenFound 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
|
🟢 Tests passed during RECORDING mode: 🟢 No issues found for passed tests after REPLAYING rerun. 🟢 All tests passed! |
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Tests analyticsTotal tests: 1316 Click here to see the affected service packages
Action takenFound 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected tests
|
|
🟢 Tests passed during RECORDING mode: 🟢 No issues found for passed tests after REPLAYING rerun. 🟢 All tests passed! |
Does the file IO cause the provider generation time much longer? |
Tests analyticsTotal tests: 1316 Click here to see the affected service packages
🟢 All tests passed! View the build log |
|
The examples files are read automatically and then parsed during the template execution with the function To avoid reading the files twice, one for parsing, and the other one for validation, we can read the files once. We can first read the file content manually for each file, and then parse the content using The content of the example file can be used for variables validation. Does this option make sense? |
Yeah, that option makes sense. I'm a little confused at the structure of ExecuteTemplate though. ExecuteTemplate within examples.go seems to be the central place that Go templates are executed through for the entire provider generation (resources... types... etc go through here). It's not limited to example generation, so it doesn't make sense to modify it for example-specific behavior. I can split off ExecuteTemplate to be specific to *Examples, but I'm not sure if that's worth it. |
Sorry for the confusion. The other generation (resources, tests and docs) uses the template in |
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Tests analyticsTotal tests: 1321 Click here to see the affected service packages
🟢 All tests passed! View the build log |
zli82016
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for the fix.
Rebasing the main branch is needed to address the unit test failure.
17e386f to
73fd6c0
Compare
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are.
|
Tests analyticsTotal tests: 1321 Click here to see the affected service packages
🟢 All tests passed! View the build log |
dcd9144
Why don't we add this as a unit test instead. Similar to https://github.com/ScottSuarez/magic-modules/blob/c3e7ad903b246f3f92ed5191ee526e485adf3bf4/mmv1/validate_third_party_test.go |
|
For both cases could they be returned by the compiler as warnings, and upgraded to errors in CI? Unit tests are unlikely to be run by contributors locally, while errors at runtime can block development. Warnings w/ warn2err in CI would theoretically both notify folks in local runs & enforce compliance. |
My nit is adding compilation runtime for what I would consider unit test behavior. I agree that the user would catch more often before proposing a pr if apart of build, but I am not sure it is worth an impact to overall build time. Pending the actual impact to build time it is likely a non issue. It is just the more of the things like this we do, deaths by a thousand cuts. |
|
Fair consideration! I think bazel may allow us to parallelise more (especially if we integrate more deeply over time, i.e. breaking service packages into dedicated build rules) and will help keep latency down. If it doesn't or we do see runtime increases we'd want to restructure, yeah. |
Fixes: hashicorp/terraform-provider-google#15679 (comment)
Check Vars and TestEnvVars to make sure that all variables used in examples have values specified in YAML configs. This does add significant file IO as we have to read every example file prior to generating tests.
Release Note Template for Downstream PRs (will be copied)
See Write release notes for guidance.