Last step of publish is selecting the wrong merge target

After a release we merge the release branch back to the base branch:

https://github.com/getsentry/craft/blob/78d2ca9c4bae075ce45ca888b94c86e176d9848f/src/commands/publish.ts#L331-L363

Unfortunately it looks like our algorithm for determining which branch to merge into if not explicitly provided is wrong. The past two sentry releases have merged back into the wrong branch:

https://github.com/getsentry/publish/runs/4218472116?check_suite_focus=true#step:8:123 → https://github.com/getsentry/sentry/commit/9ae170c4b3b2fd608caabb37e9ce08281d5e4747

https://github.com/getsentry/publish/runs/3909141316?check_suite_focus=true#step:8:666 → https://github.com/getsentry/sentry/commit/b15920f0c741c35f70dab85b3b2b76ffa0317602

The result is that (at least) the CHANGES file in the sentry repo has not been updated since 21.9.0 … we’re missing all of the new changelog-y goodness!

https://github.com/getsentry/sentry/blob/master/CHANGES

[jan-auer]

I might have a solution to this. Depending on whether I can get to it, I will try to push up a PR and test this locally.

For background: The current approach searches the current branches history for branch annotations. This assumes that the base branch has not moved in the meanwhile, e.g. master still points to a direct ancestor.

My idea is based on https://stackoverflow.com/a/17843908. Instead, use git show-branch to search for the nearest ancestor commit (marked with a *) that resides in a different branch. Example borrowed from the stack overflow answer with the relevant ancestor commit marked:

 A---B---D <-main (e.g. on version 2.0)
      \
       \
        C---E*---I <-maintenance/1.x
             \
              \
               F---G---H <-release/1.7.0

[BYK]

@BYK is that something you remember considering initially, or any gotchas on your end before i go down the rabbit hole?

@jan-auer I chose the current method in https://stackoverflow.com/a/55238339/90297 due to the reasons they listed under “Why did not show-branch work for me”. I did not encounter them but the last case kind of looked possible (develop vs master for hotfixes). I think we can try the other approach and see if it actually gives us any headaches.