Add patch approvals for Docker #32
Conversation
…e' and 'docker-compose' managers to the patch approval rule.
non-pinned.json
Outdated
| "prConcurrentLimit": 0, | ||
| "prHourlyLimit": 0, | ||
| "branchConcurrentLimit": 0, | ||
| "rebaseWhen": "conflicted", |
There was a problem hiding this comment.
What's wrong with the default auto?
auto: Renovate will autodetect the best setting. It will use behind-base-branch if configured to automerge or repository has been set to require PRs to be up to date. Otherwise, conflicted will be used instead
There was a problem hiding this comment.
I didn't realize that the devops repository had the setting to require the branch to be up-to-date before merging. The default value of auto should work.
There was a problem hiding this comment.
This doesn't seem to be working as expected here and after the above was removed from devops Renovate started updating after every commit. Do we see a negative with being explicit here? I'd like to ensure less updates to all these.
There was a problem hiding this comment.
The negative is that you expect a different behaviour when those settings are enabled in the repository. I'd probably prefer we set this in specific repos explicitly for when auto doesn't work.
There was a problem hiding this comment.
The more important question to me is "why rebase when not conflicted?". Independent of this not working as documented, why do we want to rebase outside of conflicts? It just seems unnecessary, and I don't want to be held to whatever Renovate does when we don't want it. This change can come back, here and org-wide.
📔 Objective
This PR enables rebasing of Renovate PRs only on conflicts and adds the
dockerfileanddocker-composemanagers to need approval for patch PRs.⏰ Reminders before review
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes