This tutorial explains how to deploy a Go application which is using Go Modules to manage its dependencies. To handle the version management of the dependencies, please follow the offical Go Modules guide, this page will focus on the deployment of the app. Go Modules can be used starting with Go 1.11.

Configuration

The go.mod file allows for arbitrary comments. This buildpack utilizes build constraint style comments to track Scalingo build specific configuration which is encoded in the following way:

• // +scalingo install <packagespec>[, <packagespec>]: a space separated list of the packages you want to install. If not specified, this defaults to .. Other common choices are: ./cmd/... (all packages and sub packages in the cmd directory) and ./... (all packages and sub packages of the current directory). The exact choice depends on the layout of your repository though.

  Example: // +scalingo install ./cmd/... ./special

• // +scalingo goVersion <version>: the major version of go you would like Scalingo to use when compiling your code. If not specified, it uses the version specified in the go.mod file. Exact versions (ex go1.16.1) can also be specified if needed, but is not generally recommended. Since Go doesn’t release .0 versions, specifying a .0 version will pin your code to the initial release of the given major version (ex go1.16.0 == go1.16 without auto updating to go1.16.1 when it becomes available).

  Example: // +scalingo goVersion go1.11

If a top level vendor directory exists and the go.sum file has a size greater than zero, go install is invoked with -mod=vendor, causing the build to skip downloading and checking of dependencies. This results in only the dependencies from the top level vendor directory being used.