aabouzaid
commented
1 week ago I had a similar issue where the tags were created from a feature branch then merged to the main branch.
The workaround we had is after each release, we updated the release-please config bootstrap-sha and last-release-sha with the release commit.
We automated that but still annoying and unnecessary.
Is your feature request related to a problem? Please describe.
release-pleasecurrently expects all your release commits to be on the same branch you are releasing from. This doesn't work when you have multiple, long-lived release branches.Our release process works as follows:
mainmainat the feature-set we want to releaseWe are usually supporting at least the last 2 minors with patch releases. Using the
--target-branchfeature ofrelease-please, we are able to release from these release branches, but since the release tags are on a commit on theses branches (which is desired), future releases on other branches can't find them. As a result,release-pleasedoesn't find the correct previous release sha to compare to.Describe the solution you'd like I'd like an option, like
--consider-all-branchesthat when specified, does not limit the search of commits for released shas to the current branch. Of course, we don't want to look at every commit ever in the repo, so in this flow I suggest release please uses github's graphql api for comparing commits between two shas.Describe alternatives you've considered I tried writing a custom GitHub action that brought in a lot of release-please code as a library, but that was a much more code to maintain than the changes necessary in
release-pleaseto support them.Additional context I have an initial solution that I will PR after creating this issue. It's a draft at the moment, as it needs some testing, but I want to get buy in on the approach before investing more time.