Update Along a GitHub Dependency's Branch [with Bazel]

[cpsauer]

What would you like Renovate to be able to do?

It would be awesome to be able to autoupdate along a particular branch of a GitHub-sourced dependency from Bazel.

As a background example: I was trying to autoupdate boringssl in a bazel workspace, for which you have to track the master-with-bazel branch. Renovate currently pulls the dependency back toward new commits on master--even when there are even newer commits on the master-with-bazel branch and when the current commit is only on the master-with-bazel branch, breaking this kind of use case.

The current best workaround I've through of is to fork the dependent repository and set up a pull bot to keep it's default branch in sync with the non-default branch of the upstream repo, but that's fairly hacky.

(This issue follows up on discussion #18360)

If you have any ideas on how this should be implemented, please tell us here.

Ideally, it'd be great if Renovate automatically updated to the tip of the branch the current commit is on, having determined that branch automatically. The reasoning is that if someone is pointing to a commit on a branch, they almost certainly intend to be on that branch.

I do see some challenges there: A commit can be on multiple branches, so you'd need to update to the newest tip of the branches the current commit is on, and that could lead to a branch switch in some edge cases. Perhaps the best solution would be to do this as the default, raising an issue if it's ambiguous. Still, automatically doing the right thing in what I'm guessing is the vast majority of cases would be pretty valuable.

Specifying the branch manually would also be okay, either through some special syntax in the WORKSPACE or in renovate.json.

Tagging @rarkins and @zharinov, since they were in the original discussion and it sounds like there's some related work being done.

Is this a feature you are interested in implementing yourself?

Maybe

[viceice]

i would prefer to use a comment for the branch as we do for GitHub actions.

the auto tracking would require use to pull the full repo to find out the right branch and that's probably too often ambiguous.

[rarkins]

Either a comment, or a "first class" field, which can be better for parsing. I also don't like the idea of auto detecting branches

[cpsauer]

👍🏻 Sounds like the implementation of the other is too gnarly.

Probably out of scope, since it would compromise statelessness, but one other idea that I think would probably still get most cases automatically without pulling would be to use the GitHub HEADs API to capture the branch, and then auto-save that information for the future.

[I'm also not sure what a "first class field" is, but I suspect I'll find out at some point.]