Go repositories serve the module proxy protocol (GOPROXY) the go command uses for go get, go mod download, go list -m and builds. Hosted repositories hold the versions you publish; proxy repositories cache proxy.golang.org, Athens or another module proxy.
1. Set up the go command
Put Depotex first in GOPROXY, and list your own modules in GONOSUMDB so go doesn't look them up in the public checksum database (it doesn't know them). The go command reads credentials for the address from ~/.netrc, with an API token as the password:
go env -w GOPROXY=https://depotex.example.com/repository/my-space/go/,https://proxy.golang.org,direct
go env -w GONOSUMDB=example.com/acme/*
# ~/.netrc
machine depotex.example.com login me password <API token>With a Go group as the space's default, https://depotex.example.com/repository/my-space/go/ downloads your modules and public ones (through a proxy member) from one address: GOPROXY=https://depotex.example.com/repository/my-space/go/ alone is enough.
2. Publish a version
A version is published by uploading its module zip. Let the go command build the zip from a tagged version of your repository, then upload it with Publish permission:
ZIP=$(GOPROXY=direct go mod download -json example.com/acme/tools@v1.2.0 | jq -r .Zip)
curl -f -u "me:$DEPOTEX_TOKEN" --upload-file "$ZIP" \
https://depotex.example.com/repository/my-space/go/example.com/acme/tools/@v/v1.2.0.zip- The zip is checked the way the go command checks module zips (every file under module@version/, the go command's size and name limits), and its go.mod must name the module. That go.mod becomes the version's .mod file; you can also upload .mod and .info yourself.
- Module paths with capital letters are written the way the go command does in addresses: github.com/!azure/… for github.com/Azure/….
- A version can't be replaced once published: every go.sum that uses it pins its content. New Go repositories publish once.
- The version list (@v/list) and @latest are generated from what the repository holds. The list has tagged versions only; @latest is the highest release, or the highest pre-release when there's no release.
3. Versions and policies
- Each module version is a version in Depotex: it shows in the Versions tab, and cleanup policies, quotas, quarantine and the block list apply to it.
- Block-list ranges compare versions by semver, with or without the leading v ([v1.2.0,v1.4.0) and [1.2.0,1.4.0) are the same).
- Blocked versions are left out of the version list and @latest, and their files are refused. Quarantined versions are refused too, and left out when the repository hides them.
- Cleanup policies warn before removing hosted Go versions: builds whose go.mod still requires a removed version fail.
4. Proxy repositories
Add an upstream with the Go module proxy preset (https://proxy.golang.org), or the address of Athens, Artifactory or another module proxy, allow it for the space, then create a proxy repository with it. Module files are fetched on first request and kept; version lists, @latest and branch or commit queries (@v/main.info) are re-checked after the metadata age. Checksum-database requests (sumdb/) pass through to the upstream, so GOSUMDB keeps working through Depotex. Downloads are still checked by the go command against go.sum and the checksum database.
5. In the artifact browser
Modules show by path, then their versions with their files (.zip, .mod, .info). The Install bar shows go get for the version, with the repository as GOPROXY.
6. Limits
- Hosted modules aren't in a checksum database: list them in GONOSUMDB (or GOPRIVATE). A Depotex checksum database isn't available yet.
- Hosted repositories can't resolve branches or commits (go get example.com/acme/tools@main): publish a tagged version, or use a proxy of a source that can.
- The browser doesn't read go.mod requirements yet (no Dependencies tab), and retracted versions aren't marked.
- Depotex link upstreams aren't available for Go yet.