Tag creation vs Release

[hutson]

Re-posting the following enhancement suggestion from the previous GitLab project for conventional-gitlab-releaser:

---

Posted by Marco Massarotto @brokenmass:

This project, at the moment, publish the change log by CREATING a new git tag (https://docs.gitlab.com/ce/api/tags.html#create-a-new-tag) with associated description.
This means that the tag has to exist locally but NOT on the remote gitlab otherwise the whole process fails.
It also means that's impossible to fully regenerate your past releases unless you remove the tags remotely (and not only the associated release notes), BUT not locally.

To clean this up and to make it more consistent with conventional-github-releaser I would like to modify this approach and have it create a release instead (https://docs.gitlab.com/ce/api/tags.html#create-a-new-release)
This change would be a BREAKING CHANGE, as it will require the tag to exist on both local and remote (requires git push --tags / --follow-tags before running conventional-gitlab-releaser, unless we first check if the tag exists and based on the results creates a tag or a release to make the change backward compatible.

Any thoughts ?

---

Me:

I'm sorry @brokenmass for missing this issue. I haven't been receiving GitLab notification e-mails, and I haven't put in the proper effort to address the issue.

To clean this up and to make it more consistent with conventional-github-releaser

Having looked into the differences between conventional-github-releaser and conventional-gitlab-releaser a little more, I see what you mean by conventional-gitlab-releaser being inconsistent in how it creates tags on GitLab.

requires git push --tags / --follow-tags

I'd like to avoid pushing the tags to GitLab. Using gl-got, and the GitLab API makes it a little easier to reason about expectations and to write unit tests.

unless we first check if the tag exists and based on the results creates a tag or a release

So creating a release on GitHub will create a tag if it doesn't exist, and then apply the release notes to the tag. If the tag already existed, it won't fail. It just applies the release notes to that tag.

However, conventional-gitlab-releaser does not expect the tag to exist, and it will fail if it does.

So instead, how about first trying to create an annotated tag with release notes, and if that returns a 405, assuming the tag exists, and then try to create a new release, and if that returns a 409, because the release already exists, try to update an existing release?

The latter part is not entirely consistent with conventional-github-releaser either, but I think updating the release notes is still preferred over failing. At least in my opinion.

@brokenmass what are your thoughts, and does my suggestion align with your suggestion/needs mentioned above?

---

Posted by Marco Massarotto @brokenmass:

However, conventional-gitlab-releaser does not expect the tag to exist, and it will fail if it does.

It doesn't expect it to exist on the remote, but it require it to exist locally. That means that the remote tag creation will be a bit of dark magic if done by conventional-gitlab-releaser, which role is to just create release notes.
But sure that seem like a feasible solution.

try to update an existing release?

Not really convinced by this idea. I would expect it to fail unless some sort of force flag is passed as parameter (--force-update)

Will send you a PR soon.

---

Posted by Marco Massarotto @brokenmass:

well @hutson ...
it ended becoming a major rewrite of the application, more focused on a cleaner promise like approach but still providing the ability to stream the results as they are generated.
unit tests and decent commits messages on their way
https://gitlab.com/hyper-expanse/conventional-gitlab-releaser/merge_requests/28

[HugoPoi]

I hit this hard because when I have seen this :

Recommended workflow

1. Make changes
2. Commit those changes
3. Make sure GitLab CI turns green
4. Bump version in package.json
5. Commit package.json files
6. Tag
7. Push
8. conventionalGitlabReleaser

Sounds really what I needed but for doing this workflow you need to tag for building the release in CI then publish my release in Gitlab with built assets.

[edmundo096]

Got into the same thing.
I was looking on the recommended workflow but the releaser won't work if a tag already exists on the source repo.

Also discovered (after some confusion) that there is a recommended gist on the conventional-gitlab-releaser README that does exactly that, creates a tag with npm publish then pushes tags.

I realized it was fine, because the gist uses "conventional-github-releaser" (on line 27).
So the GitLab version method works different compared to the GitHub one.

Maybe instead of using

POST /projects/:id/repository/tags

we could use the releases API instead to create it

POST /projects/:id/releases

like the GitHub version repos/${context.owner}/${context.repository}/releases