Support proxy registries for each package type

[OverkillGuy]

Feature Description

Spinning off #19270 (comment) into its own ticket as recommended

I wish Gitea supported "remote", or "proxy" repositories.

These are package repositories that proxy an external source of packages, hence configured with proxy URL, but are otherwise same as local package repositories, as they can be pulled from as usual.

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

Advantages:

• Shorter round-trip to fetch packages = faster build times
• Improved auditability of dependencies (one place for all $internet_stuff)
• Offline-able build systems helps with disaster recovery, privacy...
• Mitigate bad/rogue updates by having solid cacheing

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

Pushing this feature to its extreme, Artifactory provides Virtual Repositories that aggregate both remote (public proxies) and local (private to org) repositories into one place.

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.

Screenshots

[OverkillGuy]

Suggesting applying the label theme/package-registry, but I can't apply that on my own.

[lunny]

About what should the proxy looks like. A proxy package should have the same url and database structures as an original one but with a mirror column just like repositories and mirror repositories. So this package is readonly from user and there is an internal time to fetch from remote?

[springeye]

yes,I really need this feature

[kvaster]

Also proxy should cache data from remote. That way you may be sure you'll be able to build your project even if data is reomved from remote.

[yekanchi]

is this going to be something like Sonatype-Nexus or JFrog-Artifactory?

[TimberBro]

A proxy package should have the same url and database structures as an original one but with a mirror column just like repositories and mirror repositories.

Wouldn't it be superfluous to keep a link to a remote repository for each package?

@lunny How do you feel about the idea of having mirror settings at the organization level?
As example, for any type of registry, the owner can check whether the registry is a mirror or not and if it is, the owner can set the remote-URL.

[yekanchi]

A proxy package should have the same url and database structures as an original one but with a mirror column just like repositories and mirror repositories.

Wouldn't it be superfluous to keep a link to a remote repository for each package?

@lunny How do you feel about the idea of having mirror settings at the organization level? As example, for any type of registry, the owner can check whether the registry is a mirror or not and if it is, the owner can set the remote-URL.

I think we can merge both.

• packages could be uploaded locally without upstream source (as is now)
• if any package or package version is requested and there is no file for the specified version the upstream sources will be checked.

So there is no need to specify upstream source for every pacakge/

[PatrickHuetter]

This feature would be awesome. We are running a nexus repository server since a few years and migrated from gitlab to gitea. With this feature we could also get rid of the nexus and have a more all in one experience in our development tasks.