search

mooltiverse / nyx

The one stop semantic release tool
Apache License 2.0
113 stars 8 forks source link

Detecting previous version when merge commits are pushed #270

Open bradmac-ats opened 1 year ago

bradmac-ats commented 1 year ago

I understand that Nyx only follows the first parent in merge commits, but I've encountered what I think is a fairly normal situation where this seems to break down. I suspect there's a different workflow people are using that doesn't run into this or you would've addressed it by now, but I'm not sure what that workflow is.

What I did is:

  1. I check out a branch at commit A1, version 1.0.0
  2. I add my own commit B1 to the branch
  3. in the meantime, someone has pushed commit A2 to the server, which becomes version 1.0.1
  4. I go to push and am blocked due to being behind the server
  5. I merge the remote tracking branch into my branch, creating B2, whose first parent is B1 and whose second parent is A2
  6. I push my changes to the server. B2 gets calculated as 1.0.1, when it should be 1.0.2.

Now I've severed the latest commit from all the previous version tags as far as Nyx is concerned.

Am I missing something? how are people dealing with or preventing this issue?

flelli commented 1 year ago

Hi @bradmac-ats ,

have you tried merging with --no-commit? This should let you commit manually and get back in control of tagging.

When the same happened to me I realized I needed to improve my branching strategy to avoid these issues. I'm also curious to know if anyone has found some other way.

bradmac-ats commented 12 months ago

Sorry, I'm not following. What would I do after --no-commit to address this?

I did find a way to recover from this in my setup at least. In my setup, I'm extracting variables from Nyx's state after running infer and passing to subsequent jobs as environment variables: VERSION, IS_NEW_VERSION, IS_NEW_RELEASE, and IS_LATEST_VERSION. So if I run our GitLab pipeline manually and set those variables manually I can generate a correctly versioned release to create a new baseline for future version calculations.

It seems like automatic semantic versioning heavily favors a rebasing workflow, which had never occurred to me until I started experimenting with it. It's not a bad idea either, but I'd rather not have to force it on our development teams just to make build automation happy.

I'm guessing the issue with following both parents is related to supporting multiple release branches? And I don't see a good alternative for that if it was to follow both. Looking at the commit message for "merge remote-tracking branch" and only checking the other parent on those might hypothetically work but doesn't seem nearly as robust as anyone would like. Only other thing I can think of would be a toggle to check both parents that people could turn on if they aren't using release branches?

flelli commented 12 months ago

I agree, a toggle could be viable and people may turn it on at their own risk.

The point is that following both parents (potentially many, in case of octopus merges) could easily drive to inconsistencies in case of overlapping or unordered tags. It may even lead to re-bumping based on commits that have already been included in other releases/tags.

lxke19 commented 11 months ago

Hey @flelli ,

you redirected me to this issue, that means the problem can't be solved?

flelli commented 11 months ago

Hi @lxke19 , I just linked this issue because it brings the same request about the first parent commit so that you know where to watch for updates.

I'll give this a try and implement a toggle to enable all parents, although I'm not 100% confident it will work.

lxke19 commented 10 months ago

Hi @flelli what is the status on the merge commit implementation? Are u still working on it?

flelli commented 10 months ago

Hi @lxke19 ,

I gave it a try but things turn out to be more complicated than they seemed. I'll work on it but not in the very short time as my regular job is keeping me under pressure these times.

PullDakar commented 4 months ago

Hi, @flelli

Do you have any updates?

Maybe, if it's very complicated, you could add experimental option, which allows to disable --first-parent option. And mark this as experimental in docs

bradmac-ats commented 4 months ago

The problem is that just following both parents using the current algorithm won't get you want you/I want. I ended up creating my own little tool to get the calculation to work how I wanted. You have to follow each parent of each commit back until you find a core version, while keeping track of the largest bump you find along each path, then apply the largest bump to the highest core version, even if those occurred on different paths. Then in the case of prereleases you also check if the result is an already-used prerelease, and if so you just bump the prerelease index of the last-used prerelease version by one. I'm sure trying to fit all that into Nyx while supporting all the existing configuration options would indeed be tricky.