prometheus / golang-builder Goto Github PK

Supersedes 1.10.3.

docker image tag 1.16.3-main is missing on quay.io

I'd suggest to not set an entrypoint in the Dockerfile but leave that to the caller. The builder.sh script should be in the PATH so that one can run the docker container with docker run --rm prom/golang-builder:1.5.3-main builder.sh [options]. This will also allow to provide more than one command later, for diagnosis for example.

From https://groups.google.com/forum/#!msg/prometheus-developers/ZjWZR1kVMbg/Ym2fa43iBgAJ

They'd like to contribute building binaries for s390x but they require debian:buster because it provides crossbuild-essentials-s390x.

Thoughts on moving to :buster @SuperQ @sdurrheimer @grobie?

Go provides a json url to fetch the latest versions: https://go.dev/dl/?mode=json

We should use this data rather than polling for file download URLs.

It seems like there is a bug in the updater tool that misses updating the version of the base FROM in the main Dockerfile.

See: #234

Seems like the maintainer on this repo is old, do we plan on updating the file?

Is there a maintainer at the moment?

As I understand, the golang builder requires a Makefile providing build target. A set of environment variables will be available and there are expectations around the file location of the build output produced by the make target.

It'd be great to document this interface in the README.

Golang uses $major.$minor version names for patch version 0. Golang builder uses the same naming scheme for the "latest patch version" image. Given an image name golang-1.6 it's not clear to a go developer whether that means 1.6.3 or 1.6.0.

What do you think about using 1.6.x as image name for "the latest patch version"?

Currently, passing -T leads to the test make target being run.

It would be handy if it were possible to run the other testing-related targets (check_license, style unused, and staticcheck).

Assuming there is no objection to this, I'm happy to put up a PR. I could:

• just keep a single -T flag, and expand the set of make targets that it runs to include the above
• add some separate testing flag(s) to cover those other targets

Any preferences?

Debian 12 / bookworm is expected sometime in 2023. There are some TODO items.

riscv64

Add packages:

• libasan6-riscv64-cross
• libitm1-riscv64-cross
• libubsan1-riscv64-cross

./scripts/sync_repo_files.sh: line 71: jq: command not found
./scripts/sync_repo_files.sh: line 71: jq: command not found

to fix prometheus/prometheus#3856

To use the new user annotation API of the runtime/trace package (see prometheus/prometheus#4568 (comment)). And also to experiment with modules.

I'll send a PR soon.

Starting with the PR that introduced the 1.17 builder image into prometheus/prometheus, test results haven't been uploaded, instead rendering this error:

Unable to save test results from /root/project/test-results
Error error accessing path "/root/project/test-results": stat /root/project/test-results: no such file or directory
Found no test results, skipping

As can be seen from this run about a week earlier, this error didn't appear with the 1.16 builder image.

This is because gotestsum is somehow no longer present in 1.17.

>> running all tests
GO111MODULE=on gotestsum --junitfile test-results/unit-tests.xml -- -race -p 2 ./...

(1.16)

>> running all tests
GO111MODULE=on go test -race -p 2 ./...

(1.17)

https://github.com/prometheus/prometheus/blob/c564984daa96a9f49ab6dc3c3db9b29b580cae38/Makefile.common#L72-L79

Not sure I fully understand the intend, but we have builder.sh in both the base image as well as in main and the platform specific variants. Since the script has platform specific conditions I'm wondering whether we can just have one in the base image? Or what is the reason to have one per arch?

/cc @sdurrheimer

Fixing this CVE requires incrementing go versions to 1.21.9 and 1.22.2.

Is this likely to be done soon?

I spent some time today figuring out how all this is actually working. I think we should add just a few words to the README explaining what the builder images contain, how they get build and how we use them to cross compile. Just a few sentences would be enough.

After this change to the golang-builder base image 1.18: https://quay.io/repository/prometheus/golang-builder?tab=history&tag=latest on June 8, any crossbuilds with promu that utilize the golang-builder image is completely broken. The container cannot start:

build
bash build_ui.sh --all
build module/lezer-promql
make: *** [Makefile:48: ui-build] Error 243
!! The base builder docker image exited unexpectedly: exit status 2

This is on debian linux. I ran promu crossbuild -p windows/amd64 as well as linux/amd64, both failed with same error.

I'm trying to compile a go program to run on PowerPC (made by freescale,running in 32bit,big endian). As I can see in your guide, the powerpc environment you use is ppc 64bit little endian.
Does your docker image support PowerPC 32bit big endian?

go: downloading github.com/pkg/errors v0.8.1
2021/08/31 12:22:01 processing 1.16
2021/08/31 12:22:01 no version change for Go 1.16.7
2021/08/31 12:22:01 processing 1.17
2021/08/31 12:22:01 failed to detect current version of 1.17: couldn't get exact version for 1.17
exit status 1

Reported from #51 (comment)

The CI failed because OSXCROSS_SDK_URL isn't set (https://circleci.com/gh/prometheus/golang-builder/165). This relates probably to the migration from Circle CI 1.0 to 2.0 and the fact that by default, builds from forked pull requests can't access secrets (see https://circleci.com/docs/2.0/oss/#pass-secrets-to-builds-from-forked-pull-requests).

Not sure what is the fix for this problem.

The script 'builder.sh' under 1.6/arm/rootfs folder has mentioned 'common.sh' file as source. But there is no file present under '1.6/arm/rootfs/' dir.