search

dhoulb / multi-semantic-release

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

there's a way to create only tags and avoid releases? #118

Open IGZangelcostales opened 2 years ago

IGZangelcostales commented 2 years ago

Hello team, I use this project with GitLab to version many packages in monorepo. It works great! thank you so much for your work.

Now I'm looking to avoid creating releases for every component; I just need to get the tags but not create a release for every tag. I want to create a separate job that will create a unique release, and I just want to see my new custom releases in the GitLab releases dashboard, not thousand of releases of every individual component.

Would this be possible? I am a bit of a novice at this. Again, thank you for your help.

reuzel commented 1 year ago

I think this is tricky. multi-semantic-release will work from the latest found tag in git. Running msr in a separate job on the same branch will analyse the commits since the last tag. When tags are already set in a build job, there are no commits since last tag in your release job, letting msr think there is nothing to release.

A tag in msr is a pointer to a release. Decoupling this does not make sense. If you would like to split development and production releases, then the anticipated way is to run msr from seperate development and production (e.g. main) branches. In the development branches, tags get the form of 1.2.3-alpha for example. Running msr from production, these merged commits would result in the 1.2.3 production release. By playing with CICD configurations (splitting dev and prod release steps), multiple msr configs can exist side-by-side. This allows you to skip some release steps in development (performing just the alpha tagging), while the production config would result in a full release (whatever that may mean in your environment).

antongolub commented 1 year ago

The main problem is deps bumping: msr needs to know not only versions of the prev released packages (tags), but also how the deps of their dependants was bumped (1.0.0 or ^1.0.x). I could not figure out how to get around this limitation, and we just started from scratch.