1
0
mirror of https://github.com/goreleaser/goreleaser.git synced 2024-12-27 01:33:39 +02:00
goreleaser/main.go

73 lines
1.5 KiB
Go
Raw Permalink Normal View History

2017-04-21 20:25:32 +02:00
package main
import (
"os"
_ "embed"
goversion "github.com/caarlos0/go-version"
fix: set parallelism to match Linux container CPU (#3901) <!-- Hi, thanks for contributing! Please make sure you read our CONTRIBUTING guide. Also, add tests and the respective documentation changes as well. --> Currently Goreleaser uses `runtime.NumCPU()` as the default value if `--parallelism` is not set. However, this will get the number of CPUs on the host even when Goreleaser is run in a container with a limit on the maximum number of CPUs that can be used (typically in a Kubernetes pod). Actually, `docker run --cpus=1 goreleaser/goreleaser --debug` shows `parallelism: 4` on my machine. This behavior causes CPU throttling, which increases execution time and, in the worst case, terminates with an error. I ran into this problem with Jenkins where the agent runs on pod ([Kubernetes plugin for Jenkins](https://plugins.jenkins.io/kubernetes/)). This commit introduces [automaxprocs](https://github.com/uber-go/automaxprocs) to fix this issue. This library sets `GOMAXPROCS` to match Linux container CPU quota. I have also looked for a library that can get CPU quota more directly, but this seems to be the best I could find. The reason it is set in a different notation from the automaxprocs README is to prevent logs from being displayed ([comment](https://github.com/uber-go/automaxprocs/issues/18#issuecomment-511330567)). I would have liked to write a test, but this change is dependent on the number of CPUs in the execution environment, so I could not. Instead, I wrote a Dockerfile for testing ```Dockerfile FROM golang:1.20.2 WORKDIR /go/app RUN sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d -b /usr/local/bin COPY . . RUN task build ``` and confirmed built binary shows expected parallelism by following commands: ```sh docker build --file Dockerfile.test . -t test-goreleaser docker run --cpus=1 test-goreleaser ./goreleaser build --snapshot --debug # parallelism: 1 docker run test-goreleaser ./goreleaser build --snapshot --debug # parallelism: 4 ``` I also ran the built binary on my Macbook and it was fine.
2023-04-02 22:16:41 +02:00
"github.com/caarlos0/log"
"github.com/charmbracelet/lipgloss"
"github.com/goreleaser/goreleaser/v2/cmd"
"github.com/muesli/termenv"
fix: set parallelism to match Linux container CPU (#3901) <!-- Hi, thanks for contributing! Please make sure you read our CONTRIBUTING guide. Also, add tests and the respective documentation changes as well. --> Currently Goreleaser uses `runtime.NumCPU()` as the default value if `--parallelism` is not set. However, this will get the number of CPUs on the host even when Goreleaser is run in a container with a limit on the maximum number of CPUs that can be used (typically in a Kubernetes pod). Actually, `docker run --cpus=1 goreleaser/goreleaser --debug` shows `parallelism: 4` on my machine. This behavior causes CPU throttling, which increases execution time and, in the worst case, terminates with an error. I ran into this problem with Jenkins where the agent runs on pod ([Kubernetes plugin for Jenkins](https://plugins.jenkins.io/kubernetes/)). This commit introduces [automaxprocs](https://github.com/uber-go/automaxprocs) to fix this issue. This library sets `GOMAXPROCS` to match Linux container CPU quota. I have also looked for a library that can get CPU quota more directly, but this seems to be the best I could find. The reason it is set in a different notation from the automaxprocs README is to prevent logs from being displayed ([comment](https://github.com/uber-go/automaxprocs/issues/18#issuecomment-511330567)). I would have liked to write a test, but this change is dependent on the number of CPUs in the execution environment, so I could not. Instead, I wrote a Dockerfile for testing ```Dockerfile FROM golang:1.20.2 WORKDIR /go/app RUN sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d -b /usr/local/bin COPY . . RUN task build ``` and confirmed built binary shows expected parallelism by following commands: ```sh docker build --file Dockerfile.test . -t test-goreleaser docker run --cpus=1 test-goreleaser ./goreleaser build --snapshot --debug # parallelism: 1 docker run test-goreleaser ./goreleaser build --snapshot --debug # parallelism: 4 ``` I also ran the built binary on my Macbook and it was fine.
2023-04-02 22:16:41 +02:00
"go.uber.org/automaxprocs/maxprocs"
2017-04-21 20:25:32 +02:00
)
//nolint:gochecknoglobals
2017-04-21 20:25:32 +02:00
var (
version = ""
commit = ""
treeState = ""
date = ""
builtBy = ""
2017-04-21 20:25:32 +02:00
)
func init() {
// enable colored output on github actions et al
if os.Getenv("CI") != "" {
lipgloss.SetColorProfile(termenv.TrueColor)
}
fix: set parallelism to match Linux container CPU (#3901) <!-- Hi, thanks for contributing! Please make sure you read our CONTRIBUTING guide. Also, add tests and the respective documentation changes as well. --> Currently Goreleaser uses `runtime.NumCPU()` as the default value if `--parallelism` is not set. However, this will get the number of CPUs on the host even when Goreleaser is run in a container with a limit on the maximum number of CPUs that can be used (typically in a Kubernetes pod). Actually, `docker run --cpus=1 goreleaser/goreleaser --debug` shows `parallelism: 4` on my machine. This behavior causes CPU throttling, which increases execution time and, in the worst case, terminates with an error. I ran into this problem with Jenkins where the agent runs on pod ([Kubernetes plugin for Jenkins](https://plugins.jenkins.io/kubernetes/)). This commit introduces [automaxprocs](https://github.com/uber-go/automaxprocs) to fix this issue. This library sets `GOMAXPROCS` to match Linux container CPU quota. I have also looked for a library that can get CPU quota more directly, but this seems to be the best I could find. The reason it is set in a different notation from the automaxprocs README is to prevent logs from being displayed ([comment](https://github.com/uber-go/automaxprocs/issues/18#issuecomment-511330567)). I would have liked to write a test, but this change is dependent on the number of CPUs in the execution environment, so I could not. Instead, I wrote a Dockerfile for testing ```Dockerfile FROM golang:1.20.2 WORKDIR /go/app RUN sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d -b /usr/local/bin COPY . . RUN task build ``` and confirmed built binary shows expected parallelism by following commands: ```sh docker build --file Dockerfile.test . -t test-goreleaser docker run --cpus=1 test-goreleaser ./goreleaser build --snapshot --debug # parallelism: 1 docker run test-goreleaser ./goreleaser build --snapshot --debug # parallelism: 4 ``` I also ran the built binary on my Macbook and it was fine.
2023-04-02 22:16:41 +02:00
// automatically set GOMAXPROCS to match available CPUs.
// GOMAXPROCS will be used as the default value for the --parallelism flag.
if _, err := maxprocs.Set(); err != nil {
log.WithError(err).Warn("failed to set GOMAXPROCS")
fix: set parallelism to match Linux container CPU (#3901) <!-- Hi, thanks for contributing! Please make sure you read our CONTRIBUTING guide. Also, add tests and the respective documentation changes as well. --> Currently Goreleaser uses `runtime.NumCPU()` as the default value if `--parallelism` is not set. However, this will get the number of CPUs on the host even when Goreleaser is run in a container with a limit on the maximum number of CPUs that can be used (typically in a Kubernetes pod). Actually, `docker run --cpus=1 goreleaser/goreleaser --debug` shows `parallelism: 4` on my machine. This behavior causes CPU throttling, which increases execution time and, in the worst case, terminates with an error. I ran into this problem with Jenkins where the agent runs on pod ([Kubernetes plugin for Jenkins](https://plugins.jenkins.io/kubernetes/)). This commit introduces [automaxprocs](https://github.com/uber-go/automaxprocs) to fix this issue. This library sets `GOMAXPROCS` to match Linux container CPU quota. I have also looked for a library that can get CPU quota more directly, but this seems to be the best I could find. The reason it is set in a different notation from the automaxprocs README is to prevent logs from being displayed ([comment](https://github.com/uber-go/automaxprocs/issues/18#issuecomment-511330567)). I would have liked to write a test, but this change is dependent on the number of CPUs in the execution environment, so I could not. Instead, I wrote a Dockerfile for testing ```Dockerfile FROM golang:1.20.2 WORKDIR /go/app RUN sh -c "$(curl --location https://taskfile.dev/install.sh)" -- -d -b /usr/local/bin COPY . . RUN task build ``` and confirmed built binary shows expected parallelism by following commands: ```sh docker build --file Dockerfile.test . -t test-goreleaser docker run --cpus=1 test-goreleaser ./goreleaser build --snapshot --debug # parallelism: 1 docker run test-goreleaser ./goreleaser build --snapshot --debug # parallelism: 4 ``` I also ran the built binary on my Macbook and it was fine.
2023-04-02 22:16:41 +02:00
}
}
2018-11-08 02:04:49 +02:00
func main() {
cmd.Execute(
buildVersion(version, commit, date, builtBy, treeState),
os.Exit,
os.Args[1:],
)
}
const website = "https://goreleaser.com"
//go:embed art.txt
var asciiArt string
func buildVersion(version, commit, date, builtBy, treeState string) goversion.Info {
return goversion.GetVersionInfo(
goversion.WithAppDetails("goreleaser", "Deliver Go Binaries as fast and easily as possible", website),
goversion.WithASCIIName(asciiArt),
func(i *goversion.Info) {
if commit != "" {
i.GitCommit = commit
}
if treeState != "" {
i.GitTreeState = treeState
}
if date != "" {
i.BuildDate = date
}
if version != "" {
i.GitVersion = version
}
if builtBy != "" {
i.BuiltBy = builtBy
}
},
)
}