hostRules.readOnly

[rarkins]

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.

[viceice]

What about graphql post?

[rarkins]

Good point, we probably want to differentiate between read-only graphql and mutating.

[zharinov]

Yeah, probably we should name the rule field something more high-level, e.g. readOnly

[rarkins]

OK

[rarkins]

Goal: be able to support a read-only github.com token which works for release and release notes lookups

[zharinov]

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 { matchHost: "api.github.com", readOnly: true, token: "..." }, it should work for all hostRule values in the request, and this logic will be a bit trickier than what we have now.

[rarkins]

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

[zharinov]

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

[rarkins]

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

[renovate-release]

🎉 This issue has been resolved in version 37.319.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 37.319.0

Your semantic-release bot 📦🚀