You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As for selectively enabling experimental rules, instead of enabling all rules by providing an "experimental" flag.
Would we not be able to "avoid" the config check, warning text etc. if we turn it around and let it work the same way as the "stable" rules does?
So if one would want to use 2 out of 3 experimental rules, then they use the "experimental" flag and then create an exclusion for the experimental rule they do not want?
As for selectively enabling experimental rules, instead of enabling all rules by providing an "experimental" flag. Would we not be able to "avoid" the config check, warning text etc. if we turn it around and let it work the same way as the "stable" rules does?
So if one would want to use 2 out of 3 experimental rules, then they use the "experimental" flag and then create an exclusion for the experimental rule they do not want?
Right, excellent point. I wrote this up in a hurry and didn't think through it. I think your solution makes the most sense.
New rules, particularly ones which replace deprecated rules (see #184) should be introduced with an "experimental" flag.
Experimental rules would not be added/run automatically
Experimental rules can be enabled with a CLI flag. This would allow users to "dry run" the latest changes against their dashboards/repositories.
The text was updated successfully, but these errors were encountered: