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
Support proxy registries for each package type #21223
Comments
Suggesting applying the label theme/package-registry, but I can't apply that on my own. |
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? |
This comment was marked as duplicate.
This comment was marked as duplicate.
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. |
is this going to be something like Sonatype-Nexus or JFrog-Artifactory? |
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? |
I think we can merge both.
So there is no need to specify upstream source for every pacakge/ |
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. |
This is a highly requested feature. From the characteristics of the registry operating in proxy mode:
We really hope for this feature. |
I think we can have two types proxies, one is a feature of Gitea which can connect to the source packages directly and pull. Another is an external proxy which could be depolyed in a DMZ and can pull packages from external of the network and then push to Gitea. |
Yes, a good option. It is important that the registry proxy has a cache to speed up the retrieval of packages, without having to request them from the outside each time. |
Feature Description
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:
$internet_stuff
)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
The text was updated successfully, but these errors were encountered: