Update preset to automerge lockFileMaintenance

[trmartin4]

🎟️ Tracking

PM-14677 Change lockfile PRs to automerge

📔 Objective

Modify default behavior for lockfile maintenance to automerge.

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 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

[trmartin4]

Should we consider condensing the schedule to once a week?

[Hinton]

Have we identified how we would get renovate to bypass review requirements? At the same time it would be nice to have this be opt-in to ensure the appropriate jobs as set as blocking merge.

[trmartin4]

Have we identified how we would get renovate to bypass review requirements?

Right, thank you for the reminder. I think the only one we have to deal with is the native-messaging-test-runner https://github.com/bitwarden/clients/blob/e91741b1466428303d5cd3429525c83b39ed5841/.github/CODEOWNERS#L95-L96, right? Can we add an exclusion like this? bitwarden/clients#11970

At the same time it would be nice to have this be opt-in to ensure the appropriate jobs as set as blocking merge.

Do you mean opt-in at the repo level?

[withinfocus]

Oscar is speaking about the PR requirements pretty sure. In almost all repos we have the check run for security scans that creates a failure until someone approves its run, although it's not a required workflow so I am pretty sure Renovate could merge even with its failure. That said, some repos like clients also use the check run for build steps, therefore subsequent ones are skipped until it's approved; however, the test step does not use the check run and builds and tests right off the PR (secrets aren't available, so some steps are simply bypassed) so ... we're back to being in an a mergeable state I think. I looked into all this more and https://docs.renovatebot.com/configuration-options/#platformautomerge stuck tells me that with our PR requirement that tests pass (this is on now for our branch protection, not sure why it wasn't before) Renovate will wait until that's done and then merge.

[withinfocus]

With respect to opting in, you could make a copy of default.json and offer it alongside, so some repos could request lockfile automerge.

[Hinton]

All our repositories are configured to require a reviewer before it can be merged. Can we tell github to bypass this for renovate?

Yes opt-in on repository level, since you want to prevent failing builds and tests from being automatically merged.

[withinfocus]

We could, but ... I don't want that open-ended for it as a bot and we can't configure the override for just certain types of PRs (that I know of).

[trmartin4]

How is this different than what we're already doing, for example, for the version bump: bitwarden/clients#11850? We appear to be satisfying that requirement with a review from github-actions[bot]. Is this not a pattern we want to use elsewhere?

[withinfocus]

bw-ghapp is our own bot we maintain for explicit operations.

[trmartin4]

Abandoning this PR as we do not want to grant the Renovate user the permissions required to auto-merge.