Curious to know more?
Here are some of the frequently asked questions:
With the introduction of Go Modules in Go 1.11 the community is adopting a different approach. The dependencies are now cached on your computer are binary archives of the source files and should not be checked into the source control. Instead, go now resolves missing dependencies directly as binaries or as sources which are packed into binaries before they can be used as dependencies.
If vendoring is working for you at the moment, you do not need GoCenter.
Current resolution of modules uses git clone command to fetch the module archive if it exists, or the sources if it is missing (most of the libraries today don’t distribute a pre-packaged archive). Not only git clone is not optimized for massive concurrent downloads by CI servers across the world, packaging modules from scratch on the client every time the module is needed is time-consuming. GoCenter distributes pre-packaged immutable modules over HTTP.
Two additional benefits provided by GoCenter is immutability and persistence.
While a GitHub author can remove the module in any time, destroying your build reproductivity, a pre-built artifact of the dependency will remain cached in GoCenter. GoCenter is a source for immutable modules, provided by their authors. We make sure that once the module is added to GoCenter, its metadata and the content of the binary archive won’t change, and you will always consistently get the same binary for the same request.
GoCenter doesn’t host any unique content. You can switch to another source of dependencies in any time by only change the value of
GOPROXY environment variable.
While we made sure that the most popular modules are already there, anyone can request a module inclusion. As long as the module has an open source, an OSS license and popular enough (stars threshold on GitHub), its sources will be automatically downloaded, packaged and made available for use. The same process will be applied to this module’s transitive dependencies, making sure all the dependency graph can be successfully resolved from GoCenter.
We respect the original license and copyright; generated go metadata files are under the MIT license.
Immutability is important since having immutable dependencies is the only way to guarantee a reproducible build. If you aren’t sure that module A version 1 is the same artifact today as it was six months ago, you can’t be sure that the code dependent on it behaves the same. Unfortunately, GitHub can’t provide immutability guarantees for at least two reasons:
- GitHub allows force-pushing content to an existing tag, removing the immutability promise of a tag.
- Also, if an author removes a project from GitHub, someone else can create another project under the same name and release binaries under same coordinates, but with completely different content.
Once we step away from vendoring, we are dealing with a hierarchy of caches, each having their pros and cons:
- Local cache: Exists on your computer. Provides immediate access. Not shared. Not reliable (can be wiped at any moment).
- Organizational cache: JFrog Artifactory or Athens. Provides faster (Intranet) access. Provides reproducible builds as it caches the dependencies used once for build reproduction. Requires team infrastructure. Requires effort to get modules into the cache and maintain them (cleanups, backups, availability).
- Public cache: GoCenter. Provides fast access. Provides reproducible builds as it caches the popular and requested dependencies from version control. Highly available, requires no maintenance from the user and free to use.
Since each one of the layers serves a different purpose for different scenarios, JFrog Artifactory or Athens are not a replacement for GoCenter.
GoCenter is free and does not require any action apart of setting the
GOPROXY variable. Once set, your builds are now faster and reproducible.
Google has announced plans to introduce a central Go Modules repository (“Google-run module mirror”) in August, 2019. Like JFrog GoCenter, this service (will) pull modules from original sources and will package and serve them as immutable, trusted modules. We’re excited to see Google acknowledge the pain points that JFrog is currently solving for the community with GoCenter and JFrog Artifactory. Google also plans to offer concrete APIs and surrounding services around Module Mirrors, including a public feed for new modules. We look forward to working with Google and other vendors to integrate these services into GoCenter once they become available, and to continue to improve the ecosystem of public, trusted Go modules.