4
votes
  • I have Artifactory set up and working, serving other artifacts (RPM, etc)
  • I would like to have local copies of public and private Go programs and libraries
    • to ensure version consistency
    • to let public repositories get bugs out
    • to let public repositories secure from unauthorized alterations
  • I've created a Go repository in Artifactory, and populated it with, as an example, spf13/viper using frog-cli (which created a zip file and a mod file)

Questions:

  1. Is the zip file the proper way to store Go modules in Artifactory?
  2. How does one use the zip file in a Go program? E.g. the URL to get the zip file is http://hostname/artifactory/reponame/github.com/spf13/viper/@v/v1.6.1.zip (and .mod for the mod file) E.g., do I set GOPATH to some value?
  3. Is there a way to ensure all requirements are automatically included in the local Artifactory repository? At the time of the primary package's (e.g. viper) inclusion into the local Artifactory repository?
1
I think what you're looking for is Go Module Proxy. Give this a read: arslan.io/2019/08/02/why-you-should-use-a-go-module-proxy - shmsr

1 Answers

3
votes

Answering 3rd question first -

Here's another article that will help - https://jfrog.com/blog/why-goproxy-matters-and-which-to-pick/. There are two ways to publish private go modules to Artifactory. The first is a traditional way i.e. via JFrog CLI that's highlighted in another article.

Another way is to point a remote repository to a private GitHub repository. This capability was added recently. In this case, a virtual repository will have two remotes. The first remote repository defaults to GoCenter via which public go modules are fetched. The second remote repository points to private VCS systems.

Setting GOPROXY to ONLY the virtual go modules repository will ensure that Artifactory continues to be a source of truth for both public and private go modules. If you want to store complied go binaries, you can use a local generic repository but would advise using a custom layout to structure the contents of a generic repository.

Answering the first 2 questions -

Go module is a package manager in Golang similar to what maven is for Java. In Artifactory, for every go module, there are 3 files for every go module version: go.mod, .info, and the archive file.

Artifactory follows the GOPROXY protocol, hence the dependencies mentioned in the go.mod will be automatically fetched from the virtual repository. This will include the archive file too which is a collection of packages (source files).

There's additional metadata that's stored for public go modules such as tile and lookup requests since GoSumDB requests are cached to ensure that Artifactory remains the source of truth for modules and metadata even in an air-gapped environment.