Skip to content
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

fix: use channel as package name for generic_package upload #607

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

phuocnb
Copy link

@phuocnb phuocnb commented Sep 28, 2023

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
Copy link
Author

phuocnb commented Sep 28, 2023

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.

Copy link
Contributor

@JonasSchubert JonasSchubert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -88,11 +88,14 @@ export default async (pluginConfig, context) => {

if (target === "generic_package") {
// Upload generic packages
const encodedLabel = encodeURIComponent(label);
const { major, minor, patch } = semver.parse(version);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

// https://docs.gitlab.com/ee/user/packages/generic_packages/#publish-a-package-file
uploadEndpoint = urlJoin(
gitlabApiUrl,
`/projects/${encodedRepoId}/packages/generic/release/${encodedVersion}/${encodedLabel}?${
`/projects/${encodedRepoId}/packages/generic/${encodedChannel}/${encodedVersion}/${encodedLabel}?${
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

@phuocnb phuocnb Sep 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is my Package Registry on a private gitlab repo.

The repo home page

Screenshot from 2023-09-29 09-01-55

The channel released assets

Screenshot from 2023-09-29 09-02-46

Screenshot from 2023-09-29 09-06-13

The release detail

Screenshot from 2023-09-29 09-25-48

You may notice that it is organized much better.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@fgreinacher fgreinacher Oct 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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}"
          }
        ]
      }
    ]
  ]
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

const encodedLabel = encodeURIComponent(label);
const { major, minor, patch } = semver.parse(version);
const encodedVersion = `${major}.${minor}.${patch}`;
const encodedLabel = encodeURIComponent(label ?? version);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I notice this too.

Copy link
Contributor

@fgreinacher fgreinacher Oct 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

phuocnb commented Sep 29, 2023

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 phuocnb marked this pull request as draft September 29, 2023 02:16
@fgreinacher
Copy link
Contributor

fgreinacher commented Oct 5, 2023

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
Copy link
Author

phuocnb commented Nov 4, 2023

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
Copy link
Author

phuocnb commented Nov 8, 2023

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants