Go Releaser Ignores Parallelism

[ryancurrah]

We have been troubleshooting an issue in CI where a lot of CPU cores are being used, we identified that the issue is related Go Releaser. This has been happening for longer than 3 months as far as we can tell, so not sure if it's related to Go Releaser v2 or a more recent update.

It appears that Go Releaser is ignoring the --parallelism flag.

Below is an output in our CI (that has been obfuscated), you will notice we set parallelism set to 10 but in monitoring we see the build task taking all CPU cores on the build node.

ARTIFACTS_BASE_URL="https://artifactory.example.com/artifactory" \
ARTIFACTS_ARCHIVE_REPOSITORY="archive-repo/obfuscated" \
ARTIFACTS_DEBIAN_REPOSITORY="deb-repo/obfuscated" \
DOCKER_REGISTRY_URL="docker-registry.example.com" \
DOCKER_REGISTRY_PATH="obfuscated" \
GIT_BRANCH="branch-obfuscated" \
HOSTNAME="build-host-obfuscated" \
UNAME="Linux build-host-obfuscated X.Y.0-generic #134-obfuscated SMP <timestamp> x86_64 GNU/Linux" \
goreleaser build --parallelism=10 --clean --snapshot 
  • by using this software you agree with its EULA, available at https://goreleaser.com/eula
  • running goreleaser v2.7.0 (latest v2.8.2)
  • only  version: 2  configuration files are supported, yours is  version: 0 , please update your configuration
    • importing .goreleaser.common.yml
  • skipping validate...
  • cleaning distribution directory
  • loading environment variables
  • getting and validating git state
    • couldn't find any tags before "<tag-obfuscated>"
    • git state                                      commit=<hash> branch=<branch-obfuscated> current_tag=<tag-obfuscated> previous_tag=<unknown> dirty=true
    • pipe skipped                                   reason=disabled during snapshot mode
  • parsing tag
  • setting defaults
    • pipe skipped                                   reason=release is disabled
  • snapshotting
    • building snapshot...                           version=<tag-obfuscated>
  • running before hooks
    • running hook                                   hook=./internal/utils/obf_vendor/download_so.sh <version> linux x86_64 ./internal/utils/obf_vendor
  • ensuring distribution directory
  • setting up metadata
  • writing release metadata
  • loading go mod information
  • build prerequisites
  • building binaries
    • building                                       binary=dist/serviceA_linux_amd64_v1/obf.serviceA
    • building                                       binary=dist/serviceB_linux_amd64_v1/obf.serviceB
    • building                                       binary=dist/serviceC_linux_amd64_v1/obf.serviceC
    • building                                       binary=dist/serviceD_linux_amd64_v1/obf.serviceD
    • building                                       binary=dist/serviceE_linux_amd64_v1/obf.serviceE
    • building                                       binary=dist/serviceF_linux_amd64_v1/obf.serviceF
    • building                                       binary=dist/serviceG_linux_amd64_v1/obf.serviceG
    • building                                       binary=dist/serviceH_linux_amd64_v1/obf.serviceH
    • building                                       binary=dist/serviceI_linux_amd64_v1/obf.serviceI
    • building                                       binary=dist/serviceJ_linux_amd64_v1/obf.serviceJ
    • building                                       binary=dist/serviceK_linux_amd64_v1/obf.serviceK
    • building                                       binary=dist/serviceL_linux_amd64_v1/obf.serviceL
    • building                                       binary=dist/serviceM_linux_amd64_v1/obf.serviceM
    • building                                       binary=dist/serviceN_linux_amd64_v1/obf.serviceN
    • building                                       binary=dist/serviceO_linux_amd64_v1/obf.serviceO
    • building                                       binary=dist/serviceP_linux_amd64_v1/obf.serviceP
    • building                                       binary=dist/serviceQ_linux_amd64_v1/obf.serviceQ
    • building                                       binary=dist/serviceR_linux_amd64_v1/obf.serviceR
    • building                                       binary=dist/serviceS_linux_amd64_v1/obf.serviceS
    • building                                       binary=dist/serviceT_linux_amd64_v1/obf.serviceT
    • building                                       binary=dist/serviceU_linux_amd64_v1/obf.serviceU
    • building                                       binary=dist/serviceV_linux_amd64_v1/obf.serviceV
    • building                                       binary=dist/serviceW_linux_amd64_v1/obf.serviceW
    • building                                       binary=dist/serviceX_linux_amd64_v1/obf.serviceX
    • building                                       binary=dist/serviceY_linux_amd64_v1/obf.serviceY
    • building                                       binary=dist/serviceZ_linux_amd64_v1/obf.serviceZ
    • took: 4m42s
  • setting up metadata
  • storing artifacts metadata
  • build succeeded after 4m55s
  • thanks for using GoReleaser Pro!

[ryancurrah]

Looking at the code, GoReleaser does respect the --parallelism flag:

goreleaser/cmd/build.go

Lines 155 to 159 in 0edafa6

	ctx.Parallelism = runtime.GOMAXPROCS(0)
	if options.parallelism > 0 {
	ctx.Parallelism = options.parallelism
	}
	log.Debugf("parallelism: %v", ctx.Parallelism)

It defaults to GOMAXPROCS for internal parallelism but overrides it if --parallelism is explicitly set.

What I suspect is happening: GoReleaser is correctly limiting concurrency to 10 builds, but each go build is still using 10 CPU threads because we’ve set GOMAXPROCS=10 in the environment.

That results in 10 × 10 = 100 CPU threads, oversaturating the CI node.

We could try setting GOMAXPROCS=1 and keeping --parallelism=10 to cap total CPU usage to ~10 cores.

Question: does GoReleaser explicitly pass the GOMAXPROCS env var through to the go build subprocess? From what I can tell, it likely inherits the env as-is, but I haven’t found where that’s confirmed in the code yet.

[caarlos0]

I don't think it does, but it should! Good catch

[caarlos0]

see #5699

[ryancurrah]

Commented.

[caarlos0]

improved docs about it: #5712

thanks @ryancurrah 💌