You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be useful to have an API endpoint to assign a repo to a newly uploaded package.
Currently, whenever a package with a new name is uploaded, it is not associated with a git repo, and must be linked manually. There is an item in the Package Registry related ToDo list, "Set repository link from package metadata". This sounds great, but may not be possible in all cases.
I'd like an API endpoint to link a package to a git repo manually.
Use case: self-built kernel .deb packages. Debian packages for linux kernels include the version number in the name, so that users can decide for themselves when to delete an older kernel. But this means the name of the package varies and doesn't match the repo name, so automatic links may not be possible.
To illustrate this, say I have a linux machine named foo, and set up custom kernel builds for it. I would build and upload two packages:
linux-image-6.6.6-foo (version 6.6.6-1), a custom build of the 6.6.6 kernel for foo
linux-image-foo (version 6.6.6-1), an empty package which depends on linux-image-6.6.6-foo
This package naming convention matches the way distropackages work.
I'd configure foo to use gitea as an apt repo, and I'd apt install linux-image-foo to install the custom kernel. So far so good.
Then later on, I build a newer kernel version:
linux-image-6.6.7-foo (version 6.6.7-1), a custom build of the 6.6.7 kernel for foo
linux-image-foo (version 6.6.7-1), an empty package which depends on linux-image-6.6.7-foo
The new linux-image-foo package updates the previous one, but linux-image-6.6.7-foo appears in the gitea UI as a new package and is not linked to the gitea repo.
I do not believe it would be possible to automatically link packages in this case. So I would like a way for buildbots to set the link directly. Does an endpoint already exist to do this? I wasn't able to find one... but I suspect some endpoints may be missing from the swagger docs (see #30597).
This is largely cosmetic; the apt repo works fine, the only problem is navigation in the gitea UI.
Screenshots
No response
The text was updated successfully, but these errors were encountered:
Feature Description
It would be useful to have an API endpoint to assign a repo to a newly uploaded package.
Currently, whenever a package with a new name is uploaded, it is not associated with a git repo, and must be linked manually. There is an item in the Package Registry related ToDo list, "Set repository link from package metadata". This sounds great, but may not be possible in all cases.
I'd like an API endpoint to link a package to a git repo manually.
Use case: self-built kernel .deb packages. Debian packages for linux kernels include the version number in the name, so that users can decide for themselves when to delete an older kernel. But this means the name of the package varies and doesn't match the repo name, so automatic links may not be possible.
To illustrate this, say I have a linux machine named
foo
, and set up custom kernel builds for it. I would build and upload two packages:This package naming convention matches the way distro packages work.
I'd configure foo to use gitea as an apt repo, and I'd
apt install linux-image-foo
to install the custom kernel. So far so good.Then later on, I build a newer kernel version:
The new linux-image-foo package updates the previous one, but linux-image-6.6.7-foo appears in the gitea UI as a new package and is not linked to the gitea repo.
I do not believe it would be possible to automatically link packages in this case. So I would like a way for buildbots to set the link directly. Does an endpoint already exist to do this? I wasn't able to find one... but I suspect some endpoints may be missing from the swagger docs (see #30597).
This is largely cosmetic; the apt repo works fine, the only problem is navigation in the gitea UI.
Screenshots
No response
The text was updated successfully, but these errors were encountered: