fix: use channel as package name for generic_package upload

[phuocnb]

The current generic_package upload does not satisfy what actual needs. We don't always release on the official release channel.

According to gitlab url format:
/projects/:id/packages/generic/:package_name/:package_version/:file_name?status=:status

What i did:

• package_name equal to channel (release, alpha, beta, rc, etc)
• package_version always requires in format major.minor.patch (required from gitlab generic package upload)
• file_name is treated as the label config (if the label value does not exist, it would take version value instead)

[phuocnb]

It actually does not correct if the configuration provide a regex path (may match multiple files to upload).
I will update the file_name to take the basename of actual uploading file instead of using label.

[JonasSchubert]

IMO the option to configure the package name is a good idea.
But I would only provide this configuration option and would not change other functionalities.
Unit tests should be added, too.

[JonasSchubert]

If I understand that correct, this renders it impossible to use prereleases (alpha, beta).

[fgreinacher]

Yes, this does not look correct. GitLab allows much more:

The package version. The following regex validates this: \A(.?[\w+-]+.?)+\z. You can test your version strings on Rubular.

[JonasSchubert]

In the Gitlab documentation this changed part is the package name.
I would suggest, if we change this, to either use the package name or allow to provide a name for assets.
IMO the semantic release channel is not the correct way to go.

[phuocnb]

This is my Package Registry on a private gitlab repo.

The repo home page

The channel released assets

The release detail

You may notice that it is organized much better.

[JonasSchubert]

It does look clean and well organized, yes.
My concerns are regarding users trying to use package names instead of channels.

[phuocnb]

I see.
It's better add it as an optional configuration.
Old users will not be forced to change their existing projects.

[fgreinacher]

I like the structure too, but I would not enforce it to all users.

Maybe let's just a configuration option for asset.packageName and make that templatable. Then you could configure it something like this:

{
  "branches": ["main"],
  "plugins": [
    [
      "@semantic-release/gitlab",
      {
        "assets": [
          {
            "path": "dist/asset.min.js",
            "label": "JS distribution",
            "target": "generic_package",
            "packageName": "${nextRelease.channel}"
          }
        ]
      }
    ]
  ]
}

[phuocnb]

@fgreinacher thank you for the suggestion.
I'm implementing it that way and will push new code soon.

[JonasSchubert]

IMO the fallback to the version is confusing. The version will then be the file name and package version

[phuocnb]

I notice this too.

[fgreinacher]

asset.label can be templated, so that should be solvable via configuration, see https://github.com/semantic-release/gitlab#usage, and we don't need to change the core logic.

[phuocnb]

IMO the option to configure the package name is a good idea. But I would only provide this configuration option and would not change other functionalities. Unit tests should be added, too.

I would update the implementation and add unit tests later when the implementation has been approved.

[fgreinacher]

IMO the option to configure the package name is a good idea. But I would only provide this configuration option and would not change other functionalities. Unit tests should be added, too.

I would update the implementation and add unit tests later when the implementation has been approved.

@phuocnb Feel free to go on and ping me if you're stuck somewhere!

[phuocnb]

IMO the option to configure the package name is a good idea. But I would only provide this configuration option and would not change other functionalities. Unit tests should be added, too.

I would update the implementation and add unit tests later when the implementation has been approved.

@phuocnb Feel free to go on and ping me if you're stuck somewhere!

I were so busy in the last 2 months.
I'm back to this today.

[phuocnb]

@fgreinacher @JonasSchubert
Depends on a testing project on gitlab, i'm pretty sure that this label config will not work in case of using generic_package

"@semantic-release/gitlab",
{
        "gitlabUrl": "https://gitlab.com",
        "assets": [
	        {
		        "path": "assets/single-file.md",
		        "label": "Single Label",
		        "target": "generic_package"
	        }
        ]
}

The upload request actually return a 400 HTTP Error code.

This is the full job log
failed-job.txt

---

After running the above job, the result is:

• A new tag has been created
• No release is created
• Nothing is uploaded to generic package

---

Changing the label value to match the filename and the job would be succeeded.

"@semantic-release/gitlab",
{
        "gitlabUrl": "https://gitlab.com",
        "assets": [
	        {
		        "path": "assets/single-file.md",
		        "label": "single-file.md",
		        "target": "generic_package"
	        }
        ]
}

---

In the publish.js:

line 98-103

uploadEndpoint = urlJoin(
              gitlabApiUrl,
              `/projects/${encodedRepoId}/packages/generic/release/${encodedVersion}/${encodedLabel}?${
                status ? `status=${status}&` : ""
              }select=package_file`
            );

line 115-118

const url = urlJoin(
              gitlabApiUrl,
              `/projects/${encodedRepoId}/packages/generic/release/${encodedVersion}/${encodedLabel}`
            );

I believe that encodedLabel should be changed to encodedFilename (which is calculated from file path).

This is the original issue that i want to commit a fix on this PR.

Anyway, i still working on this issue (on another branch).
Since the PR does not allow me to change the source branch, do you have any suggestion to let me do it?