Overview

JFrog Artifactory offers support for Go packages, providing:

  1. Secure, private Go registries with fine-grained access control over Go packages according to projects or development teams.
  2. Remote Go registries which provide proxy and caching functionality for remote Go resources. 
  3. Enterprise features such as high availability, repository replication for multi-site development and different options for massively scalability storage.
  4. A full solution with JFrog CLI, allowing you to resolve and publish your Go projects.

Installing Go

Artifactory requires Go client version 1.11.0 and above.

To install the Go client, please refer to the .

You can also install the Go client by running:

brew install go

GoCenter Central Public Repository

 is a central public repository for OSS Go modules hosted and maintained by JFrog. Already populated with tens of thousands of Go modules, it is one of the primary resources for Go project dependencies.

To configure a remote Go registry in Artifactory to proxy GoCenter, please refer to Remote Repositories

<a href="https://jfrog.com/integration/artifactory-go-registry/ " target="blank"> JFrog Artifactory and Go Registry </a>




Configuration

Local Repositories

To deploy Go packages to a local Go registry and enable calculation of Go package metadataselect Repositories | Repositories | Local and set Go to be the Package Type when you create your local repository.

Remote Repositories

Artifactory only supports resolution of Go packages from virtual Go repositories. To resolve Go from other local or remote Go repositories, you need to aggregate them in a virtual Go repository.

A remote Go repository in Artifactory serves as a caching proxy for GoCenter, GitHub.com or a Go repository in a different Artifactory instance.

Artifacts (such as zip files) requested from a remote Go registry are cached on demand. You can remove downloaded artifacts from the remote repository cache, however you can not manually deploy artifacts to a remote repository. 

Proxying GoCenter

To define a remote repository to proxy GoCenter, follow the steps below:

  1. In the Administration module, under Repositories | Repositories | Remote, click New Remote Repository
  2. In the New Repository dialog, set the Package Type to Go, set the Repository Key value, and https://gocenter.io in the URL field as displayed below.
  3. Click "Save & Finish".

Proxying GitHub

To create a Remote Repository which serves as a caching proxy for github.com, follow the steps below:

  1. Create a new remote repository and set Go to be its Package Type.
  2. Set the Repository Key value, and enter https://github.com/ in the URL field as displayed below.
  3. In the Go Settings set the Git Provider as GitHub.
  4. In the Advanced  tab, enter the username and password of your GitHub account. This is required due to a rate limit imposed by GitHub when access is anonymous.
    Note: As per the latest GitHub update, basic authentication is no longer supported via REST API. Your password must be replaced with a GitHub private access token.
  5. Also in the Advanced tab, check Lenient Host Authentication
  6. Click Save & Finish.

GitHub Proxy


Working with GOSUMDB

Go Client 1.13 introduced support for checksum verifications of modules against a central server. Artifactory is able to act as the central checksum server for the Go clients using it as the Go proxy. This will work without any additional configurations for remote sites pointing to GoCenter, GitHub or another Artifactory server.

It is possible to override the default central server used by Artifactory to provide the checksums by adding the property ' artifactory.go.sumdb.url.override=https://...' to your Artifactory's system properties

This feature can be disabled by adding the property 'artifactory.go.sumdb.enabled=false' to your Artifactory's system properties

Private GitHub repositories and some remote sites do not provide checksums. The Go client in those cases will complain about missing the checksum. You can control this feature on the client side with the GOPRIVATE and GONOSUMDB environment variables. See the Go 1.13 Modules environment variables for full details.

Virtual Repositories

If you are publishing your Go builds to a Virtual Repository, make sure to set one of the local Go repositories that it aggregates as the Default Deployment Repository.

A Virtual Repository defined in Artifactory aggregates packages from both local and remote repositories.
This allows you to access both locally hosted Go packages and packages from remote proxied Go registries from a single URL defined for the virtual repository.

To create a virtual repository as a Go registry, in the Administration module, under Repositories | Repositories | Virtual, click New Virtual Repository and set Go to be its Package Type, and select the underlying local and remote repositories to include under the Repositories section.

Advanced Configuration

Some  may use go-import meta tags on the remote repository response body to declare the location of a remote VCS root to follow. By default, this behavior is enabled, and Artifactory will follow these tags to download remote modules. To disable this uncheck the Follow 'go-import' Meta Tags checkbox.

Follow 'go-import' Meta Tags
When checked (default), Artifactory will automatically follow remote VCS roots in go-import meta tags to download remote modules. 
'go-import'  Whitelist
A white list of Ant-style path patterns that determine which remote VCS roots Artifactory will follow to download remote modules from when presented with go-import meta tags in the remote repository response. By default, this is set to ** which means that remote modules may be downloaded from any external VCS source.

For example, if you wish to limit remote go-import modules to only be downloaded from github.com, you should remove the default ** pattern and replace it with **/github.com/**.



Using Go with Artifactory

Much of your work with Go and Artifactory is done through JFrog CLI, a thin client that wraps the Go client. To learn more, please refer to the JFrog CLI User Guide.

 JFrog CLI is, itself, written in Go

Resolving Go Projects

Artifactory only supports resolution of Go packages from virtual Go repositories. To resolve Go from other local or remote Go repositories, you need to aggregate them in a virtual Go repository.

go.mod is a metadata file that describes a Go package. It contains the package's module name and a list of its dependencies.

To allow successful resolution of a package, the Go client requires a corresponding go.mod file to be found in the same folder.

For example, in this Hello Worlds Go project, the go.mod file specifies a module github.com/you/hello, with a single dependency, rsc.io/quote v1.5.2.

module github.com/you/hello
require rsc.io/quote v1.5.2

Resolving Transitive Dependencies Locally

To fully resolve a Go project, each transitive dependency needs to have its corresponding go.mod file in place in the same folder where it resides. However, in many cases, the go.mod file does not exist. To resolve a Go project in this case, follow these steps:

  1. Manually download all required dependencies from the internet to your local machine
  2. Run your build while resolving dependencies locally
  3. Publish your built package to Artifactory as described below.

From this point on, you can rebuild your project while resolving dependencies from Artifactory   

Building Go Packages

To build your Go projects, use JFrog CLI. JFrog CLI downloads the dependencies needed for the project from the internet and creates the corresponding go.mod file. When you later use JFrog CLI to publish your package to Artifactory, the go.mod file is uploaded alongside the package to Artifactory.

For details, please refer to the JFrog CLI documentation

Publishing Go Projects

The Go client works through a Git repository which hosts the Go package source code, and does not provide a way to directly publish packages to Artifactory.

To publish your package to Artifactory, use JFrog CLI as described in the JFrog CLI documentation

If you are publishing your Go builds to a Virtual Repository, make sure to set one of the local Go repositories that it aggregates as the Default Deployment Repository.