-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Product/File version in Windows executables #3414
Comments
Jaeger binaries support "version" subcommand, is that not enough? |
Thanks for the information. It's a little bit hidden. As addition to the subcommand the product/file version would be very nice to have |
I don't know if Go compiler supports setting these properties on the Windows binary, but I don't have any objections to including them. |
Sorry, I am not familiar with Go and Go compiler. |
Hi can I take this? |
@smolgeat sure |
Hi @yurishkuro.
I don't think there's a straightforward way to apply such configurations with Go Compile. but I am thinking to use a 3rd party service/repo to embed such info through a |
That might be ok, I would recommend checking what other projects do (e.g. does Hugo have Windows binaries? Do they tag them like that?) |
looking for a beginner-friendly issue if this is available |
it is |
Hey can I work on this? |
Yes |
/assign |
Hi @pocki I am a first time contributor, can you please guide on how to get started here and where I need to make the changes in order to solve the issue? |
As you can see above, I am also not familiar with Go and the Go Compiler. |
I see references to two utilities that seem to achieve this: https://stackoverflow.com/questions/35126344/how-to-set-the-file-version-field-in-pe-header-of-exe-files |
Hi, @pocki @yurishkuro i tried to clone the repository but don't have the required access rights. Can you help me with that? |
you need to clone into your personal namespace, e.g. ananyak19/jaeger |
## Which problem is this PR solving? This resolves #3414 ## Description of the changes Add to the windows build step in `Makefile` to create a `resource.syso` using [goversioninfo](https://github.com/josephspurrier/goversioninfo). The version is extracted from the latest git tag. `go build` will embed this information in the final executable ![image](https://github.com/jaegertracing/jaeger/assets/6261556/5c45219c-4528-4000-b5af-cd0fd1e2a421) (Forgive the German in this screenshot) ## How was this change tested? 1. Run ` make build-binaries-windows` 2. Navigate to the folder containing binaries (e.g. ` cmd/agent/agent-windows-amd64`) 3. Add `.exe` to the file name for the changes to be seen: `agent-windows-amd64.exe` Ran other targets (`make build-binaries-linux`) to see if it broke other targets. Looked fine so far. ## Notes There is the hassle of creating a `.syso` file that must be in the [same directory as the main.go file](golang/go#16090 (comment)) so there's a lot of copying to each `cmd/*`. I tried to keep it centralized to a `prepare-winres` Makefile target and the files are cleaned up afterwards. ## Checklist - [x] I have read https://github.com/jaegertracing/jaeger/blob/master/CONTRIBUTING_GUIDELINES.md - [x] I have signed all commits - [ ] I have added unit tests for the new functionality - [x] I have run lint and test steps successfully - for `jaeger`: `make lint test` - for `jaeger-ui`: `yarn lint` and `yarn test` Signed-off-by: Julien Midedji <[email protected]>
Requirement - what kind of business use case are you trying to solve?
Actual the windows executables (jaeger-agent.exe, jaeger-collector.exe, ...) don't have a version set. It is hard to identify the current used version and check if the actual used version is outdated.
Problem - what in Jaeger blocks you from solving the requirement?
Checking the actual used version and identity an outdated version.
We have some applications running native on Windows (Server) and therefore the agent is also running native on Windows.
Proposal - what do you suggest to solve the problem or improve the existing situation?
Set the Product and/or File Version of the windows executables on compile or release.
Any open questions to address
The text was updated successfully, but these errors were encountered: