You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This could be probably solved either in a form of a boolean flag or an optional transform function. What would be also nice is to have a transform function for the message field, which currently defaults to Release x.x.x. Someone may want to see smth like Release x.x.x (YYYY-MM-DD), for instance.
Me:
@kachkaev I believe the value passed to tag_name is nothing more than the tag created by the following line. Therefore, perhaps we can update semantic-release-gitlab to prepend a v, and allow that to propagate to semantic-release-gitlab-releaser and semantic-gitlab-notifier? Thoughts on that idea?
As for your second idea, would you mind breaking that out into a separate issue? As for the transform function idea, I like the idea. I think it's fantastic. The only issue we'll need to keep in mind is that the arguments we pass to conventional-gitlab-releaser need to match conventional-github-releaser. We plan on merging the two projects together in the future.
Alexander Kachkaev @kachkaev:
Thanks for your reply @hutson!
Looks like that line is not the only one that needs changing. In index.js of conventional-gitlab-releaser the remote tag on GitLab is derived from the semver again. I'm using this package separately from semantic-release-gitlab and still can't get v in the version.
Perhaps, something like tagPrefix: 'v' could be an alternative to a boolean flag, but I can't remember any repos that would use any other convention for semantic tags rather than D.D.D or vD.D.D.
@kachkaev the boolean proposal for conventional-gitlab-releaser looks fine with me. Please feel free to submit a pull request to add that option.
Alexander Kachkaev @kachkaev:
I'm not sure I'll find time for this @hutson. Feel free to reuse my code in a new PR! I might be back when I find a need to use your library again, it really helped me last year 😉
The text was updated successfully, but these errors were encountered:
Re-posting the following enhancement suggestion from the previous GitLab project for
conventional-gitlab-releaser
:Alexander Kachkaev
@kachkaev
:At the moment tagname is hardcoded to have a format of
D.D.D
. It would be nice if users could also releasevD.D.D
(e.g. like GitLab does this itself)Alexander Kachkaev
@kachkaev
:This could be probably solved either in a form of a boolean flag or an optional transform function. What would be also nice is to have a transform function for the message field, which currently defaults to
Release x.x.x
. Someone may want to see smth likeRelease x.x.x (YYYY-MM-DD)
, for instance.Me:
@kachkaev
I believe the value passed totag_name
is nothing more than the tag created by the following line. Therefore, perhaps we can updatesemantic-release-gitlab
to prepend av
, and allow that to propagate tosemantic-release-gitlab-releaser
andsemantic-gitlab-notifier
? Thoughts on that idea?As for your second idea, would you mind breaking that out into a separate issue? As for the transform function idea, I like the idea. I think it's fantastic. The only issue we'll need to keep in mind is that the arguments we pass to
conventional-gitlab-releaser
need to match conventional-github-releaser. We plan on merging the two projects together in the future.Alexander Kachkaev
@kachkaev
:Thanks for your reply
@hutson
!Looks like that line is not the only one that needs changing. In index.js of
conventional-gitlab-releaser
the remote tag on GitLab is derived from the semver again. I'm using this package separately fromsemantic-release-gitlab
and still can't getv
in the version.Possible solution:
How about this?
Perhaps, something like
tagPrefix: 'v'
could be an alternative to a boolean flag, but I can't remember any repos that would use any other convention for semantic tags rather thanD.D.D
orvD.D.D
.Alexander Kachkaev
@kachkaev
:Re. release transform function: https://gitlab.com/hyper-expanse/conventional-gitlab-releaser/issues/5
Me:
@kachkaev
the boolean proposal forconventional-gitlab-releaser
looks fine with me. Please feel free to submit a pull request to add that option.Alexander Kachkaev
@kachkaev
:I'm not sure I'll find time for this
@hutson
. Feel free to reuse my code in a new PR! I might be back when I find a need to use your library again, it really helped me last year 😉The text was updated successfully, but these errors were encountered: