Support proxy registries for each package type

### Feature Description > Spinning off https://github.com/go-gitea/gitea/issues/19270#issuecomment-1200472188 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](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/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

Posted by OverkillGuy on Sep 20, 2022, 11:10 PM

Tags

• support (Software)

Related issues

• Add 65536 size support for maps
• TypeScript 7.1 Iteration Plan
• nvim-treeconfig: upstream nvim-treesitter
• Add the "action" and "method" attributes to <button>
• [FEATURE] Support multiple Connector accounts (same connector, different accounts) in Claude and Claude Code on the web (claude.ai/code)
• > We were imposed GitHub for so many exercises!