Skip to content

Correct ldflags to set version, commit and build host (during offline builds)? #7471

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kastl-ars opened this issue Mar 28, 2025 · 7 comments

Comments

@kastl-ars
Copy link

Short description

I am trying to package OPA for openSUSE. It seems that the ldflags that I found in the documentation are not working.

https://github.com/open-policy-agent/opa/blob/main/docs/content/extensions.md?plain=1#L385

go build -o opa++ -ldflags "-X github.com/open-policy-agent/opa/version.Version=MY_VERSION" main.go

I noticed that the variables seem to be related to v1 somehow:

https://github.com/open-policy-agent/opa/blob/v1.3.0/version/version.go#L24

var (
	Vcs       = v1.Vcs
	Timestamp = v1.Timestamp
	Hostname  = v1.Hostname
)

Indeed, using github.com/open-policy-agent/opa/v1/version.Hostname=example.org (with a v1) allows setting the build hostname.

I have packaged dozens of go packages, but am pretty inexperienced with golang and its internals. So it might well be an error on my side.

Kind Regards,
Johannes

Steps To Reproduce

  1. Build using this command
go build \
   -mod=vendor \
   -ldflags=" \
   -X github.com/open-policy-agent/opa/version.Version=9.9.9\
   -X github.com/open-policy-agent/opa/version.Vcs=COMMIT_HASH_GOES_HERE \
   -X github.com/open-policy-agent/opa/version.Hostname=build.example.org \
   -X github.com/open-policy-agent/opa/version.Timestamp=2025-03-28T12:36:25Z" \
   -o bin/opa
  1. Execute opa version
$  ./bin/opa version
Version: 1.3.0
Build Commit: 89f48353959c9b08608b6d7160c1f1c5ae2763ee-dirty
Build Timestamp: 2025-03-27T14:19:05Z
Build Hostname: 
Go Version: go1.24.1
Platform: linux/amd64
Rego Version: v1
WebAssembly: unavailable
$
  1. Notice the blank line Build host and that the version and timestamp are not what is being set in the build command.
  2. Compile again, this time using the ldflags with a /v1
  3. Execute opa version again
$ ./bin/opa version
Version: 9.9.9
Build Commit: 89f48353959c9b08608b6d7160c1f1c5ae2763ee-dirty
Build Timestamp: 2025-03-27T14:19:05Z
Build Hostname: build.example.org
Go Version: go1.24.1
Platform: linux/amd64
Rego Version: v1
WebAssembly: unavailable
$
  1. At least the version and the BuildHostname are set now, but the date is still off.

During offline builds, e.g. in the openSUSE build environment, the output is even funnier when not using v1:

Version: 1.3.0
Build Commit: 
Build Timestamp: 
Build Hostname: 
Go Version: go1.24.1
Platform: linux/amd64
Rego Version: v1
WebAssembly: unavailable

Here neither commit nor timestamp nor build hostname are being respected.

With v1 the output is kind of sensible:

Version: 1.3.0
Build Commit: 89f48353959c9b08608b6d7160c1f1c5ae2763ee
Build Timestamp: 2025-03-28T12:00:00Z
Build Hostname: build.opensuse.org
Go Version: go1.24.1
Platform: linux/amd64
Rego Version: v1
WebAssembly: unavailable
@anderseknert
Copy link
Member

Thanks for bringing that to our attention! Most of our code now resides under "v1" and the code pre-1.0 mostly just links to that. You're absolutely correct that it seems this document wasn't updated with the move, and we'll need to fix that.

@johanneskastl
Copy link

Thanks @anderseknert !

Please note that it is not only the docs. Seems like overwriting the values does not work sometimes, too. Not sure if it works when offline, i.e. no information can be fetched. Or why this is.

@anderseknert
Copy link
Member

That doesn't sound good at all! You're saying that repeating the same build command with identical build flags sometimes produces a binary with this information not included? Or does that only happen under some specific circumstances?

It could be a bug either way, but being able to reproduce this would help a lot with both categorization, prioritization and fixing it :)

@johanneskastl
Copy link

That doesn't sound good at all! You're saying that repeating the same build command with identical build flags sometimes produces a binary with this information not included? Or does that only happen under some specific circumstances?

Sorry Anders, my initial description was a little overwhelming it seems.

But comparing the result of a build command when using the v1 ldflags in e.g. a container with network connectivity shows e.g. the date not being set to the ldflags value.

While in a offline build on the openSUSE build infrastructure the version is correctly set to whatever is handed over in the ldflags.

I am not sure if there are other differences (between the build environments that I used) that cause this, the missing network connectivity is only the first thing that came to my mind.

I will try to find some time to redo the builds to see whether I messed up somewhere.

@anderseknert
Copy link
Member

Sorry for the late response! Did you get any further with this?

@johanneskastl
Copy link

Hi Anders,

sorry, I did not yet have time to redo the manual builds.
The openSUSE package properly reports the version (possibly due to the offline build).

@anderseknert
Copy link
Member

Thanks Johannes! Should we close this for the time being?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants