This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Update Along a GitHub Dependency's Branch [with Bazel] #18492
Labels
manager:bazel
Bazel WORKSPACE files
status:requirements
Full requirements are not yet known, so implementation should not be started
type:feature
Feature (new functionality)
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
The text was updated successfully, but these errors were encountered: