-
Notifications
You must be signed in to change notification settings - Fork 45
Custom tag formatting #189
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
Comments
Since I wrote this I found:
However its still not entirely clear, how one might hook in and allow a custom tag format, especially when determining the semver. If you can give me some pointers that would be helpful; I should have created this as a discussion sorry. |
I've done more research and investigation into tag support. First of all I think tag formatting would be a fairly easy way to get 99% of the way towards monorepo support (cc: #77). Afaict we can have a E.g. a parsed version of the tag format might look like Where To make it easy to specify dynamic tag formatting we could add env var injection into the template system:
So that one could do something like Then the option would be to either try and keep this tag format logic entirely inside the providers, or have some of it in the providers (like when looking at tags) but then make the semrel package aware of this format too. If you don't make semrel aware you just have to note that the Here's an example github action that would use this:
If these changes seem feasible and maintainers (CC @christophwitzko ) are interested and willing to give pointers then I'd be happy to go ahead and make this happen. |
I've attached some draft PRs to see if it's what maintainers would be keen to support |
I've done testing and I believe that it works with the current implementations now. TagFormat will be ignored for non github providers but that should be okay for now. The next thing I think that needs to happen for monorepos is that we have the ability to not perform a release but still tag. I think the best way to have this happen would be to have the success hook run at the end of a dry run still. |
I'm attempting to cause go-semantic-releases to call a target a custom plugin I've written so that I can get it to check for a next release based off a custom suffix. E.g. specify a tag format of "{{.Folder}}-v{{.Version}}". This makes easyish support for monorepo stuff.
Do you have instructions or an example anywhere of how to get semantic-release to know about a particular plugin?
The text was updated successfully, but these errors were encountered: