Configure auto-merge for patch / pinning updates

[vedantthapa]

Add renovate config to auto-merge any patch, pin or digest update types.

Some considerations:

• Changes would be required to the repository settings to enable renovate to auto-merge it's PRs.
• There are workarounds for required PR reviews.
• We'd probably want to exclude any pre 1.0.0 dependency as they can make breaking changes at any time. Here's an example to implement this.
• Finally, the way github handles skipped but required checks seems a bit weird and unless all checks pass, renovate wouldn't be able to auto-merge. They should've taken this suggestion lol.

[vedantthapa]

@Stephen-ONeil Any additional considerations that you'd wanna add?

[Stephen-ONeil]

Good research! My main thought is that I can only trust auto-merging as far as I can trust our automated testing, haha. I'd be happy to enable auto-merging while we're still pre-prod; it'll save dev cycles and help us trip over landmines (testing gaps, special package conflict cases, etc), but we would need to re-evaluate before heading to prod. Fingers crossed, it might push us to hit very solid test coverage before then.

[vedantthapa]

Hmm, skipping tests is quite straightforward to implement. On the other hand, requiring tests to pass before auto-merge is a bit complicated due to the last point mentioned in the title of this issue, which, seems more of a github thing rather than a renovate configuration.

I'll skip the tests for patch / pin update types for now and explore a workaround for the latter. That way we can potentially trip over landmines and in the meantime flesh out the workaround.

[Stephen-ONeil]

Definitely don't want to ignore tests, haha. The landmines I care about are the gaps in testing, where dependency changes automerge with passing tests but still break main.

As for the skipped-but-required issue, hm, we could update the current cloud build trigger branch regex to ignore renovate/.* branches, then add duplicates of each trigger to target just renovate branches, without the file based filters. Alternatively, we could get rid of the file based filters everywhere and just always run all the pipelines :shrug:. A little bit of wasted compute, but shouldn't be too big an issue.

[vedantthapa]

These are great ideas!

In any case, do you think it'd be helpful to add a guard condition to restrict image builds to main, similar to what we had in hopic? My main concern here is related to fast feedback rather than populating artifact registry with image build from every branch, cause the latter can be handled as a clean up policy in artifact registry.

[Stephen-ONeil]

That's the current behaviour :+1: