-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
hostRules.readOnly #28375
Comments
What about graphql post? |
Good point, we probably want to differentiate between read-only graphql and mutating. |
Yeah, probably we should name the rule field something more high-level, e.g. |
OK |
Goal: be able to support a read-only github.com token which works for release and release notes lookups |
This is the reason why I refactored the matching logic: if we specify rules like |
So readOnly=true should "win" over readOnly=false if they're both equally specified? (e.g. github.com). We might need to tweak this a bit to get right because Renovate sets hostType=github for example |
Yes, I can't describe how this should work exactly, I'll just run this on debugger and will make sure it "wins" for reasonable settings |
I think readOnly should take higher preference than hostType. e.g. a github.com readOnly token should be used for all read-only requests, regardless of whether the other token has hostType or a longer host match And if there's two matching readOnly tokens then the longer host wins, or one with hostType wins. etc |
🎉 This issue has been resolved in version 37.319.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Describe the proposed change(s).
Add a new matcher to hostRules so that the request type can be used e.g. GET, PUT, POST, etc.
This way users could give us a token for github.com which is only used for GET and can't interfere with our POST/PUT/PATCH operations.
The text was updated successfully, but these errors were encountered: