Package Registry related ToDo list #8771

@wxiaoguang commented on GitHub (Apr 3, 2022):

Some links in i18n are 404 (update: duplicate with justusbunsi's #19315 )

@wxiaoguang commented on GitHub (Apr 3, 2022): Some links in i18n are 404 (update: duplicate with justusbunsi's #19315 ) <details> ![image](https://user-images.githubusercontent.com/2114189/161408836-b554604d-9610-4121-87fa-d7ca06c0eff7.png) </details>

GiteaMirror commented

@mscherer commented on GitHub (Apr 3, 2022):

One feature that I think would benefit public forges is adding a quota system (eg, make sure a user/org can't take all the storage). While the problem already exist for repositories (folks can just commit tarball after all), I think binary packages would make it worst and limits would be easier to reach by regular users.

@mscherer commented on GitHub (Apr 3, 2022): One feature that I think would benefit public forges is adding a quota system (eg, make sure a user/org can't take all the storage). While the problem already exist for repositories (folks can just commit tarball after all), I think binary packages would make it worst and limits would be easier to reach by regular users.

GiteaMirror commented

@justusbunsi commented on GitHub (Apr 3, 2022):

Not sure if this feedback should be in this issue. If not, let me know:

Linking packages to a repository seem to not work; neither inside an organization nor for user related packages. The dropdown list cannot be opened.
Docs reference pointing to https://docs.gitea.io/en-us/<type>/ should be https://docs.gitea.io/en-us/packages/<type>/ (https://github.com/go-gitea/gitea/pull/19315)

NPM/Yarn

Support yarn add <package>
Packages with dependencies not published along with package inside Gitea will prevent a successful npm install <package>

Container Images

Pull command in package overview contains port 3000

@justusbunsi commented on GitHub (Apr 3, 2022): Not sure if this feedback should be in this issue. If not, let me know: - Linking packages to a repository seem to not work; neither inside an organization nor for user related packages. The dropdown list cannot be opened. - Docs reference pointing to `https://docs.gitea.io/en-us/<type>/` should be `https://docs.gitea.io/en-us/packages/<type>/` (https://github.com/go-gitea/gitea/pull/19315) **NPM/Yarn** - Support `yarn add <package>` - Packages with dependencies not published along with package inside Gitea will prevent a successful `npm install <package>` **Container Images** - Pull command in package overview contains port 3000

GiteaMirror commented

2025-11-02 08:17:05 -06:00

@KN4CK3R commented on GitHub (Apr 3, 2022):

Linking packages to a repository seem to not work; neither inside an organization nor for user related packages. The dropdown list cannot be opened.

That should work (for public repositories). There may be a bug which hides private repos but I could not verify that. Does the html source contains the repo names?

Support yarn add <package>

What do you mean? As addition to the npm install instruction?

Packages with dependencies not published along with package inside Gitea will prevent a successful npm install <package>

I don't think the registry should prevent that. Isn't that up to the user?

Pull command in package overview contains port 3000

That's correct and ok. If you use a "normal" port like 80 or 443 only the url is displayed. But if the registry uses a different port it needs to be specified.
be9ef15f8a/modules/setting/packages.go (L34-L37)

@KN4CK3R commented on GitHub (Apr 3, 2022): > Linking packages to a repository seem to not work; neither inside an organization nor for user related packages. The dropdown list cannot be opened. That should work (for public repositories). There may be a bug which hides private repos but I could not verify that. Does the html source contains the repo names? > Support `yarn add <package>` What do you mean? As addition to the `npm install` instruction? > Packages with dependencies not published along with package inside Gitea will prevent a successful `npm install <package>` I don't think the registry should prevent that. Isn't that up to the user? > Pull command in package overview contains port 3000 That's correct and ok. If you use a "normal" port like 80 or 443 only the url is displayed. But if the registry uses a different port it needs to be specified. https://github.com/go-gitea/gitea/blob/be9ef15f8a6346987294ae0b6185e393253f6673/modules/setting/packages.go#L34-L37

GiteaMirror commented

@justusbunsi commented on GitHub (Apr 3, 2022):

That should work (for public repositories). There may be a bug which hides private repos but I could not verify that. Does the html source contains the repo names?

I configured everything (org + repo) as private. That would explain it.
Regarding html source I need to check again. I remember there was a value for the drop down list. But nothing was visible in the UI.

What do you mean? As addition to the npm install instruction?

Yes. I had issues with using yarn add instead of npm install. I'll have another closer look at that part. Maybe I have some misconfiguration which also causes the dependency issue.

If you use a "normal" port like 80 or 443 only the url is displayed.

Thats odd. I ran the latest dev docker image of Gitea and had a reverse proxy in front of it. I even configured ROOT_URL. So my instance is available at https://git.example.com (port 443) and I am able to push the image to this endpoint. But inside the pull command port 3000 is shown.

@justusbunsi commented on GitHub (Apr 3, 2022): > That should work (for public repositories). There may be a bug which hides private repos but I could not verify that. Does the html source contains the repo names? I configured everything (org + repo) as private. That would explain it. Regarding html source I need to check again. I remember there was a value for the drop down list. But nothing was visible in the UI. > What do you mean? As addition to the npm install instruction? Yes. I had issues with using `yarn add` instead of `npm install`. I'll have another closer look at that part. Maybe I have some misconfiguration which also causes the dependency issue. > If you use a "normal" port like 80 or 443 only the url is displayed. Thats odd. I ran the latest dev docker image of Gitea and had a reverse proxy in front of it. I even configured ROOT_URL. So my instance is available at https://git.example.com (port 443) and I am able to push the image to this endpoint. But inside the pull command port 3000 is shown.

GiteaMirror commented

2025-11-02 08:17:05 -06:00

@BaseCrusher commented on GitHub (Jul 31, 2022):

I don't know if I am right with posting this here but I hope so.
Using the package registries (at least the container registry. I haven't tested the others) while the user is accessing gitea via LDAP or OIDC makes it unclear what docker/podman login should be used, since the gitea username does not have to be the same as the oidc username.
I for myself did not manage to push images with an oidc user. But this could be due to an error of mine, where I wasn't logged in correctly. Either way this case should be addressed in the docs if it works with OIDC/LDAP and if not there should be an option for those users to use the registries.

@BaseCrusher commented on GitHub (Jul 31, 2022): I don't know if I am right with posting this here but I hope so. Using the package registries (at least the container registry. I haven't tested the others) while the user is accessing gitea via LDAP or OIDC makes it unclear what docker/podman login should be used, since the gitea username does not have to be the same as the oidc username. I for myself did not manage to push images with an oidc user. But this could be due to an error of mine, where I wasn't logged in correctly. Either way this case should be addressed in the docs if it works with OIDC/LDAP and if not there should be an option for those users to use the registries.

GiteaMirror commented

2025-11-02 08:17:05 -06:00

@KN4CK3R commented on GitHub (Jul 31, 2022):

That's a good question. You can use a token to login in this case. Simply generate a token for that account and use docker login <Gitea username> <token>.

I will add it to the docs.

Edit: Here is the PR #20561 @BaseCrusher

@KN4CK3R commented on GitHub (Jul 31, 2022): That's a good question. You can use a token to login in this case. Simply generate a token for that account and use `docker login <Gitea username> <token>`. I will add it to the docs. Edit: Here is the PR #20561 @BaseCrusher

GiteaMirror commented

2025-11-02 08:17:06 -06:00

@OverkillGuy commented on GitHub (Jul 31, 2022):

Suggested feature request for package registry: Support of proxy registries for all package types.

These are package registries that proxy an external source of packages, hence configured with proxy URL, but are otherwise indistinguishable from local package registries.

Example: A local Pypi.org proxy. Local build system would use both the private package registry for "internal" (private) packages, but fetch dependencies on Pypi.org through Gitea too.

Advantages:

Shorter round-trip to fetch packages = faster build times
Improved auditability of dependencies
Offline-able build systems helps with disaster recovery, privacy...
Mitigate rogue updates

This feature in Docker repositories would remove any need for Dockerhub ECR mirror, which many have to set up to avoid Dockerhub's recent rate-limiting.

The canonical example of the feature is in JFrog's Artifactory.

Effectively, Gitea would, for these proxy repositories, become a local package cache. The biggest technical decision is about when to invalidate cache (docker image's "latest" tag moves pretty quickly, but if you already have a local copy, do you serve it as-is? even if you got it 2 years ago?)

I understand this feature can be a big investment, and acknowledge that there may be no particular need for it. I mostly envy the feature, and wish for Gitea to succeed by out-executing Artifactory, given the new Package Registry is already encroaching on that a bit.

Should I spin off this request into a standalone issue? Drop the request as too big? Happy either way, just want to surface this potential usecase that's now in reach.

EDIT: Just noticed the related ticket around "Go-proxy" which sounds like it touches on same vibes(?)

EDIT2: Standalone ticket is now: #21223

@OverkillGuy commented on GitHub (Jul 31, 2022): Suggested feature request for package registry: Support of proxy registries for all package types. These are package registries that proxy an external source of packages, hence configured with proxy URL, but are otherwise indistinguishable from local package registries. Example: A local Pypi.org proxy. Local build system would use both the private package registry for "internal" (private) packages, but fetch dependencies on Pypi.org through Gitea too. Advantages: - Shorter round-trip to fetch packages = faster build times - Improved auditability of dependencies - Offline-able build systems helps with disaster recovery, privacy... - Mitigate rogue updates This feature in Docker repositories would remove any need for [Dockerhub ECR mirror](https://github.com/onfido/ecr-mirror), which many have to set up to avoid Dockerhub's recent rate-limiting. The canonical example of the feature is in [JFrog's Artifactory](https://www.jfrog.com/confluence/display/JFROG/Smart+Remote+Repositories). Effectively, Gitea would, for these proxy repositories, become a local package cache. The biggest technical decision is about when to invalidate cache (docker image's "latest" tag moves pretty quickly, but if you already have a local copy, do you serve it as-is? even if you got it 2 years ago?) I understand this feature can be a big investment, and acknowledge that there may be no particular _need_ for it. I mostly envy the feature, and wish for Gitea to succeed by out-executing Artifactory, given the new Package Registry is already encroaching on that a bit. Should I spin off this request into a standalone issue? Drop the request as too big? Happy either way, just want to surface this potential usecase that's now in reach. EDIT: Just noticed the related ticket around "Go-proxy" which sounds like it touches on same vibes(?) EDIT2: Standalone ticket is now: #21223

GiteaMirror commented

2025-11-02 08:17:06 -06:00

@lunny commented on GitHub (Sep 20, 2022):

A standalone issue is better.

@lunny commented on GitHub (Sep 20, 2022): > A standalone issue is better.

GiteaMirror commented

2025-11-02 08:17:06 -06:00

@kotovalexarian commented on GitHub (Nov 13, 2022):

Rust (Currently no idea how to implement this one as a normal git repo is used as registry)

Are you sure? As I remember, it's just an archive. This page also doesn't mention Git as a necessity: https://doc.rust-lang.org/cargo/appendix/glossary.html

I can try to implement the support of Cargo packages. I'll look at the code soon. I see that no one tried yet.

@kotovalexarian commented on GitHub (Nov 13, 2022): > Rust (Currently no idea how to implement this one as a normal git repo is used as registry) Are you sure? As I remember, it's just an archive. This page also doesn't mention Git as a necessity: https://doc.rust-lang.org/cargo/appendix/glossary.html I can try to implement the support of Cargo packages. I'll look at the code soon. I see that no one tried yet.

GiteaMirror commented

2025-11-02 08:17:07 -06:00

@KN4CK3R commented on GitHub (Nov 13, 2022):

Yep, I'm sure. Have a look here:
https://doc.rust-lang.org/cargo/reference/registries.html#index-format

The index is stored in a git repository so that Cargo can efficiently fetch incremental updates to the index.

But you don't have to spend time on that. I already implemented the Cargo registry but did not push it yet because I wait until #21658 is merged. I need the UI part for Cargo too and don't want to add that in the PR too.

Here is a screenshot (ignore the install instructions, that's c&p from NuGet):

@KN4CK3R commented on GitHub (Nov 13, 2022): Yep, I'm sure. Have a look here: https://doc.rust-lang.org/cargo/reference/registries.html#index-format > The index is stored in a git repository so that Cargo can efficiently fetch incremental updates to the index. But you don't have to spend time on that. I already implemented the Cargo registry but did not push it yet because I wait until #21658 is merged. I need the UI part for Cargo too and don't want to add that in the PR too. Here is a screenshot (ignore the install instructions, that's c&p from NuGet): ![grafik](https://user-images.githubusercontent.com/1666336/201519484-44b8c081-0505-4526-b874-fb1419fbe48e.png)

GiteaMirror commented

2025-11-02 08:17:07 -06:00

@kotovalexarian commented on GitHub (Nov 17, 2022):

I've tried RubyGems repository. Looks like it's incomplete. While Bundler succeeded to install gems when their exact versions were specified in Gemfile.lock, it was not able to install gems without a lockfile. I'll try to investigate this, create an issue with steps to reproduce, and maybe fix this.

@kotovalexarian commented on GitHub (Nov 17, 2022): I've tried RubyGems repository. Looks like it's incomplete. While Bundler succeeded to install gems when their exact versions were specified in `Gemfile.lock`, it was not able to install gems without a lockfile. I'll try to investigate this, create an issue with steps to reproduce, and maybe fix this.

GiteaMirror commented

2025-11-02 08:17:07 -06:00

@kotovalexarian commented on GitHub (Nov 17, 2022):

Also I want to add Gitea configuration option for custom domain for packages to display it in the interface. It works well for both gem downloading and pushing with the following Nginx configuration:

server_name rubygems.example.com;

location / {
  # "gitea" is an upstream
  proxy_pass http://gitea/api/packages/rubygems/rubygems/;
  proxy_set_header Host 'git.example.com';
}

I don't want to create an issue. I'll try to implement this soon.

P.S. However I really should test if that's not the reason why Bundler doesn't work properly.

@kotovalexarian commented on GitHub (Nov 17, 2022): Also I want to add Gitea configuration option for custom domain for packages to display it in the interface. It works well for both gem downloading and pushing with the following Nginx configuration: ``` server_name rubygems.example.com; location / { # "gitea" is an upstream proxy_pass http://gitea/api/packages/rubygems/rubygems/; proxy_set_header Host 'git.example.com'; } ``` I don't want to create an issue. I'll try to implement this soon. P.S. However I really should test if that's not the reason why Bundler doesn't work properly.

GiteaMirror commented

2025-11-02 08:17:08 -06:00

@KN4CK3R commented on GitHub (Nov 21, 2022):

I added the Cargo registry with #21888.

@KN4CK3R commented on GitHub (Nov 21, 2022): I added the Cargo registry with #21888.

GiteaMirror commented

2025-11-02 08:17:08 -06:00

@lafriks commented on GitHub (Nov 22, 2022):

Would be nice to be able set specific package registry as public (without authorization) for private instances (always requiring authorization)

@lafriks commented on GitHub (Nov 22, 2022): Would be nice to be able set specific package registry as public (without authorization) for private instances (always requiring authorization)

GiteaMirror commented

2025-11-02 08:17:08 -06:00

@lafriks commented on GitHub (Dec 29, 2022):

Automatic container linking to repository would also be nice if container has source url label

@lafriks commented on GitHub (Dec 29, 2022): Automatic container linking to repository would also be nice if container has source url label

GiteaMirror commented

@KN4CK3R commented on GitHub (Dec 29, 2022):

That's already on the ToDo list (Set repository link from package metadata).

@KN4CK3R commented on GitHub (Dec 29, 2022): That's already on the ToDo list (`Set repository link from package metadata`).

GiteaMirror commented

@dr-carrot commented on GitHub (Jan 5, 2023):

Is there an api endpoint available to link the package to a repository? I don't see anything in swagger

@dr-carrot commented on GitHub (Jan 5, 2023): Is there an api endpoint available to link the package to a repository? I don't see anything in swagger

GiteaMirror commented

@KN4CK3R commented on GitHub (Jan 5, 2023):

Not yet. May come bundled with Set repository link from package metadata

@KN4CK3R commented on GitHub (Jan 5, 2023): Not yet. May come bundled with `Set repository link from package metadata`

GiteaMirror commented

@viceice commented on GitHub (Jan 9, 2023):

I would like to have readonly virtual package registries (npm /nuget), with lists all accessable packages by suppplied credentials. so i don't need to configure multiple registries (eg one for each organization).

somehow related to:

#21223

@viceice commented on GitHub (Jan 9, 2023): I would like to have readonly virtual package registries (npm /nuget), with lists all accessable packages by suppplied credentials. so i don't need to configure multiple registries (eg one for each organization). somehow related to: - #21223

GiteaMirror commented

@jcgruenhage commented on GitHub (Mar 21, 2023):

I might be wrong here, is this the right place to suggest additional package types?

I'd be interested in Ansible Galaxy support (existing implementations are https://github.com/briantist/galactory, https://github.com/ansible/galaxy, https://github.com/ansible/galaxy_ng), primarily for hosting ansible collections. The ability to host stand-alone roles is more of a legacy feature anyway.

@jcgruenhage commented on GitHub (Mar 21, 2023): I might be wrong here, is this the right place to suggest additional package types? I'd be interested in Ansible Galaxy support (existing implementations are https://github.com/briantist/galactory, https://github.com/ansible/galaxy, https://github.com/ansible/galaxy_ng), primarily for hosting ansible collections. The ability to host stand-alone roles is more of a legacy feature anyway.

GiteaMirror commented

@ExplodingDragon commented on GitHub (Apr 28, 2023):

Will the Alpine, Debian, and RPM repositories be available upon the release of version 1.19.3? I noticed that the pull request has been open for a month now.

@ExplodingDragon commented on GitHub (Apr 28, 2023): Will the Alpine, Debian, and RPM repositories be available upon the release of version 1.19.3? I noticed that the pull request has been open for a month now.

GiteaMirror commented

@KN4CK3R commented on GitHub (Apr 28, 2023):

No, we backport only fixes. As they are new features, they will available with 1.20 (if someone reviews them). You can help review the code and test the functionality.

@KN4CK3R commented on GitHub (Apr 28, 2023): No, we backport only fixes. As they are new features, they will available with 1.20 (if someone reviews them). You can help review the code and test the functionality.

GiteaMirror commented