Home > Software design >  How to add commit hash to details of an executable file
How to add commit hash to details of an executable file

Time:09-30

One of my previous employers added the GIT hash of the current commit to the "Details" tab of the file properties of the executable, once it was built.

As I found here, this command gives the current commit hash:

git rev-parse --short HEAD

But does anybody know how I can add this to the "Details" tab of the properties of a file?

CodePudding user response:

note : I'm assuming you are working on a .NET project. There are other ways to provide similar information at build time for other projects (e.g : I found this question which mentions two ways to do it for a C project)

There is a number of attributes you can set on an assembly at build time, such as the Version.

One of these attributes is : AssemblyInformationalVersionAttribute, which can be any string.

(see the docs.microsoft page on asembly attributes)

You can set it from within the code of your project, for example, in a .cs file, you can add :

[assembly:AssemblyInformationalVersionAttribute("That's my version all right")]

One way to inject the commit hash can be :

  • use a targettable string in your code :
[assembly:AssemblyInformationalVersionAttribute("#GIT_COMMIT_PLACEHOLDER#")]
  • in your build script, search and replace that string with your commit hash before building

There are tools out there that wrap this together with more complete features.

For example I have heard of Gitversion (https://gitversion.net/docs/), which integrates in Azure Devops pipelines and MSbuild tasks, and offer a swath of options to add version information to your builds from git (e.g : read the version number from tags, add commit sha, etc ...)

See the configuration and version variables pages to have a view of what you can add to your builds.

CodePudding user response:

This is really a Windows build question (and may well be build-environment specific). The method for doing this on macOS in Xcode, for instance, would be quite different.

On the Git side (since you've tagged this with ), the one thing to say about it is that rather than sticking in the output of git rev-parse --short HEAD, it's probably wiser to stick in the output of git describe, perhaps with --tags and/or --always and/or the --dirty flag:

annotation=$(git describe --always --dirty)

for instance. This way a release build will be tagged with the release tag, assuming you set up your release tags well. See the git describe documentation for details.

  • Related