-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Add check for version guards in erb templates #10297
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
Conversation
@c2thorn this isn't complete yet, but I was wondering if you could give it a quick look to make sure the approach seems reasonable, and will not be too much work to change later (assuming we ultimately stop using erb templates). I'm planning to have it run with the other mm checks against all erb files that have changed in the submitted diff. |
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
This would run as a separate check on PR's? Yeah I think this is a good approach. Seems easy enough to swap out the identifying text when we swap to Go |
Great, thanks! Yea, it would be a separate PR check, something to the effect of |
408ceba
to
cf84171
Compare
Note: this is ready for review now. The plan is to run this command in a check as a separate PR. |
cf84171
to
2684de1
Compare
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
We sometimes break downstream providers when invalid version guards are introduced in .erb files. This happens because we have 3+ versions to consider, with each being a superset of the next:
"private" or "alpha" -> "beta" -> "ga"
The typical version guard would be
<% unless version == 'ga' -%>
, which means the feature should not be available in the GA provider, but should be in Beta and Private/Alpha. Sometimes users will assume<% if version == 'beta' -%>
is equivalent, but it means the feature will NOT be available in Private/Alpha, which is almost always wrong.In short, our features should never target only beta, because it would break the assumption of Private/Alpha being a superset. This logic also works in reverse (where we wouldn't want any GA-specific functionality to also be present in Private/Alpha).
Release Note Template for Downstream PRs (will be copied)