Scalingo uses Go Modules to install dependencies for Go applications. This page explains the go.mod configuration options recognized by the Scalingo Go buildpack during deployment.

For dependency version management, refer to the official Go Modules reference.

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.