Uploaded image for project: 'Artifactory Binary Repository'
  1. Artifactory Binary Repository
  2. RTFACT-20033

Allow Artifactory to Serve Go Modules Vanity URLs



    • Type: New Feature
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Go
    • Labels:


      When users have a module using a custom module path, they need to create a Vanity URL server to translate the module name to the actual source location.

      Artifactory users should be able to use it as a Vanity URL server so they do not need to set up an additional component to resolve their modules.

      Additional Details

      When you create a Go module, the path you declare in your go.mod file to identify it is used by the Go client to reach out to the source. That is why most of the Go modules we see out there look like github.com/<ORG>/<REPO_NAME>.

      So what if I want to name my module something else, let's say myorg.com/mymodule. Somehow, when the Go client is trying to fetch it, I need to point out where the source content actually is. That is why vanity urls were introduced. Under https://myorg.com?go-get=1 I need to serve some html content with meta tags that have information about where the source code lives. The response for that request could be something like this:

      <meta name="go-import" content="myorg.com/mymodule git https://github.com/myorg/mymodule">

      So for my module to work properly, I need a web server listening for that request under my custom path and serving this content.

      I think the ask here is, since customers also want to use Artifactory to proxy and cache those modules, if it is possible to avoid having to setup another webserver just to serve those meta tags and use Artifactory for that as well, by setting up some mapping rules in the format Module Path --> Source Location and pointing the DNS rules for those custom module paths to Artifactory.

      One important thing to keep in mind is that vanity urls are ignored by the Go client when you have the GOPROXY environment variable set, since the client will delegate to the proxy to serve the content. However, they are still going to be needed by the proxy so it can find and fetch the content before serving it.

      Another important thing is, if all consumers are resolving your modules from Artifactory (GOPROXY set) you don't need vanity urls at all as long as you push your modules to Artifactory directly. Even though this should be the recommended approach, we still see people wanting to proxy their source repositories, which makes vanity urls needed.

      Also, I'm not sure if Artifactory knows how to use vanity urls as a client at this moment. I was trying to resolve sigs.k8s.io/yaml@v1.2.0 using a remote pointing to GitHub and it did not work.

      Here is some good reading about the vanity urls:




            eliom Elio Marcolino
            5 Vote for this issue
            4 Start watching this issue