search

qiwi / multi-semantic-release

Proof of concept that wraps semantic-release to work with monorepos.
BSD Zero Clause License
86 stars 34 forks source link

fix: do not use tags for normal prerelease dependency bump #96

Closed hanseltime closed 10 months ago

hanseltime commented 11 months ago

Fixes Issue 75

On Extensive debugging, the prerelease "next" logic that we use for bumping dependencies is disregarding the "_lastRelease" on a package and biasing on the git tags. This is an issue though, because we always end up having run the previous package's release thanks to the topo library, so there is a tag indicating the current release. Our desired release is this tag though and not the next increment. It is, however, the desired bump of the "_lastRelease" of that package.

Changes

To fix this, we keep a light touch by augmenting getNextPreVersion to:

  1. still consider tags if an explicit options flag is set
  2. Only consider lastRelease if not. (Which is the only way that it is used currently).

Since this is only actually used by the prerelease version and it is a well documented bug, the behavior of looking at tags is removed completely since _lastRelease should always be called by preceding packages and if not, would be handled by a failure in the preceding analyzeCommits.

antongolub commented 11 months ago

@hanseltime,

Thanks for the digging. I'm worried about default behavior changing. Maybe it's better to introduce skipTagsFetch instead?

hanseltime commented 11 months ago

@antongolub -

Sure thing. I'll update with a flag in the near future. I forgot that there may be people who have altered their workflows to circumvent this already. Will comment when I have updated it.

hanseltime commented 11 months ago

Just wanted to post here. In order for the refactor to work, I need to make a few tests, but since my mac updated all of the temporary git tests are breaking. I will be looking into it.

I will try to have it up within a week 🤞

juancarlosjr97 commented 11 months ago

I am not 100%, but would this also address indirectly the conflict of semantic release and multi-semantic-release are using the same note to check if a released can be executed or not?

See https://github.com/qiwi/multi-semantic-release/issues/98

hanseltime commented 10 months ago

This ended up being set up in different PR due to the large changes needed.

https://github.com/qiwi/multi-semantic-release/pull/97