Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
IGZangelcostales opened this issue Jun 9, 2022 · 2 comments
Open

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

IGZangelcostales opened this issue Jun 9, 2022 · 2 comments

Comments

@IGZangelcostales
Copy link

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
Copy link
Contributor

reuzel commented Jul 30, 2022

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
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants