Generic packages should include the version/tag in the download URL

I have long awaited the possibility to create "generic packages". thanks for that.

however, I'm really stymied when trying to understand how it should be used. esp. I'm having a hard-time understanding the purpose of the version field.

I'm a bit torn whether i should file this under "lack of documentation" or "outright bug", but am leaning towards the former...

Use cases

What i want to do is:

  • use generic packages as the backend for release assets (e.g. attaching a self-contained installer to a tagged release, rather than the sources-only (which comes automatically) or some zip-file containing the installer (which is possible with job artifacts)
  • use generic packages to share downloadable files outside the gitlab workflow (e.g. a releases-page that is hosted somewhere else)

What does not work?

A number of things are hindering me in my uses, and I'm not sure whether I'm just too stupid or whether the documentation lacks crucial info

no predictable download links

intuitively i would have thought, that the purpose of the "version" is for creating release-like sections. this is of course somehow possible with the current scheme, as the "version" is used to create sections on the ${CI_PROJECT_URL }-/packages page. however, it seems that the version is only used for eye-candy (display on the webpage).

more importantly, there seems to be no relation between the version and the (public) download link for the file:

E.g. Uploading a file flub.zip with version 0.1.2, will create something like ${CI_PROJECT_URL}/-/package_files/1/download (with the /1/ part being a counter that is incremented with every upload (or so).

A successful upload doesn't return the download URL at all, just an error code:

{"message":"201 Created"}

So how could I add the just attach a package to my releases page (or publish somewhere else)?

predictable download links - API only!

The documentation on generic packages thankfully includes an example how to retrieve the uploaded package via a predictable URL (that even includes the version).

Unfortunately, the example also makes it (implicitly) clear, that downloading the package via the predictable URL works only if you have access to the API.

However, using the API requires me to setup API-tokens.

That's OK if you are downloading the package from within a CI-job, but out of bounds if you are in any other context (e.g. a simple script that utilizes curl to fetch the package without using obscure URLs).

restricted version strings

As noted otherwise, the allowed version strings are severely limited.

Most notably, the version string allows only a subset of allowed tag names - but tags are the way to create versions in the project's "release" section. Why are there different restrictions? (And why are there no such restrictions e.g. with container images?)

versions vs versions

There's already a mechanism for providing versioned releases of a project: using git tags.

Why are the "generic package" versions decoupled from the release versions at all?

E.g. what is the point of uploading a package with the version 0.1.2 for the build job of tag 6.2?

conclusion

I don't see the usefulness of the version.

  • Quite obviously, it is not meant directly meant for ordinary humans (whom I expect to go to the "Release" page of a project, rather than the "Packages & Registries")
  • it doesn't allow me to create an URL (that includes the provided version) for downloading the package
  • it seems it's main purpose is for communicating the link to a specific artifact in the context of CI-jobs. but why would you use a complicated version there? wouldn't a pipeline-ID suffice at well?
  • what's the advantage of generic packages over job artifacts?

Documentation Proposal

Please clarify the use for the version field in the documentation

  • what is it for?
  • what is it not for?

Feature Proposal

  • allow any tag name to also be a version (#273034 (closed))
  • generate predicatable download links that don't involve the API. e.g. a package uploaded to ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/my_package/0.0.1/file.txt could be downloaded as ${CI_PROJECT_URL}/-/packages/generic/my_package/0.0.1/file.txt (using permissions as defined in the Project Settings)
Edited by 🤖 GitLab Bot 🤖