wrong Gitlab issue link in release notes

[safwatsafi]

Hello,

in Release notes the links of issues and commits are not correct. the link is missing "-/"

for example:
the link in release notes:
Repository_URL/issues/<issue_iid>
the link in Gitlab:
Repository_URL/-/issues/<issue_iid>

any idea how to fix this issue?

[doteric]

I have the exact same issue for almost every url. Every url is missing /-/.
For example:

• currently https://gitlab.com/repo_name/compare/1.5.1...1.5.2 , should be https://gitlab.com/repo_name/-/compare/1.5.1...1.5.2
• currently https://gitlab.com/repo_name/commit/xxxx, should be https://gitlab.com/repo_name/-/commit/xxxx

I bumped the version of all packages expecting that this was already fixed, but it looks like the issue is still present on the newest version. It looks like GitLab no longer supports urls without the /-/.

CC @travi

[travi]

from my understanding, the underlying conventional-changelog-writer should handle details like this automatically as long as your project is configured properly to specify that your project is on gitlab. for example, this sounds related to conventional-changelog/conventional-changelog#257

@fgreinacher are you familiar with the details necessary to get this working as expected?

[travi]

if you execute with the --debug flag, we do output the details that are passed to conventional-changelog-writer. could you share what that shows being detected for repository?

[fgreinacher]

I have never noticed that. Might be a change in GitLab 16?

[sylvainOL]

I guess this is what made the change:: https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=16.0#legacy-urls-replaced-or-removed

[travi]

This sounds like something that would be better handled in conventional-changelog-writer than specifically in semantic-release. Could one of you start a conversation there and reference it from here?

[safwatsafi]

we tried this for commits and issues:
"[semantic-release] › ℹ Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
semantic-release:release-notes-generator version: '1.1.0' +0ms
semantic-release:release-notes-generator host: undefined +0ms
semantic-release:release-notes-generator owner: 'xxxxxxxx' +0ms
semantic-release:release-notes-generator repository: 'xxxxxxxx/semantic-test' +0ms
semantic-release:release-notes-generator previousTag: 'v1.0.0' +0ms
semantic-release:release-notes-generator currentTag: 'v1.1.0' +1ms
semantic-release:release-notes-generator host: 'https://gitlab.com' +0ms
semantic-release:release-notes-generator linkReferences: true +0ms
semantic-release:release-notes-generator issue: '-/issues' +0ms
semantic-release:release-notes-generator commit: '-/commit' +0ms
[3:24:25 PM] [semantic-release] › ✔ Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[3:24:25 PM] [semantic-release] › ⚠ Skip v1.1.0 tag creation in dry-run mode
[3:24:25 PM] [semantic-release] › ✔ Published release 1.1.0 on default channel
[3:24:25 PM] [semantic-release] › ℹ Release note for version 1.1.0:

1.1.0 (https://gitlab.com/xxxxxxxx/semantic-test/compare/v1.0.0...v1.1.0) (2023-05-18)

Features

* #2 (https://gitlab.com/xxxxxxxx/semantic-test/issues/2) test issue 2 (10793e9 (https://gitlab.com/xxxxxxxx/semantic-test/-/commit/10793e987dxx3f3dee42be6b4e95cf4be45660ef))"

As you see, it worked for commits (/-/commit/) but not for issues

[doteric]

Hey @travi ,
As I've already mentioned here , there is no already available way for the write to handle this. The easiest approach would be to append the repository url, like I've prepared in the PR, otherwise a lot of things would need to be reworked as it's not only commits and issues that are the problem, but almost every GitLab url.

[travi]

there is no already available way for the write to handle this

help me understand. conventional-changlelog-writer currently has logic to vary it's output based on the repository host, which has been working for gitlab up to this point from my understanding. if gitlab has changed their format and conventional-changelog-writer is producing incorrect output for gitlab because it still uses the older format, it seems like the best approach would be for the logic within conventional-changelog-writer to be updated to cover the gitlab changes. since conventional-changelog-writer has more consumers than just semantic-release, it would be better for the update to improve the situation for consumers beyond semantic-release

are you trying to highlight something that is beyond the understanding that i'm outlining here?

[doteric]

@travi
So the problem is that the conventional-changelog-writer does not have any logic to support different urls based on what host is provided, this would be awful especially if the host was some custom one (self-hosted instances for example). It just accept certain parameters and uses them mostly in a clean way. The logic based on hosts is actually inside the release-notes-generator here. Inside there you modify specific values based on what git host is used, therefore it seems like release-notes-generator is the correct place to do this 🤔 Correct me if I'm wrong though as I just quickly went through the files to check the logic more or less inside both repositories.

[doteric]

So @travi what do you think about the PR?
#450
Do we want to do it that way or some different way? Let's decide on something as it's a little bit annoying that all the GitLab urls are wrong.

[travi]

@doteric please stop pinging maintainers directly for updates.

i understand that this feels urgent from your perspective, but we have to ask for your patience with this. i would never tell someone to delay updating to the latest version of a major tool, but by upgrading to a version that includes changes that break tools like semantic-release, that is a consequence of making that upgrade. before our users, like you, started reporting the breakage to us, we were unaware that this breakage was coming.

what do you think about the PR?

as i mentioned above, i believe the better place to fix this is in conventional-changelog. if you do a search in that project for "gitlab" you can find several previous conversations about formatting of gitlab urls. i could be wrong about that being the proper place, but one of the reasons we ask for patience is to have a chance to investigate further and hear back from the maintainers of conventional-changelog. in addition, semantic-release is not a full time project for any of us, so time available for our investigation is limited. beyond that context, we try very hard to avoid configuration that enables arbitrary content to be provided by users that is then injected into output like a link. it is very unlikely that we would accept such an approach unless there is no better option (and would likely require some level of input sanitization).

from my understanding, this gitlab update also broke links contained in previous releases. a fix in semantic-release would only impact links generated for new releases. until a resolution is found, new links will be broken in the same way as your previous releases. it is up to you if you go back and update previous releases, but such changes could be applied the same way to the releases impacted by this time period. another workaround could be to disable linkReferences in the config for this plugin.