Hydra executables should provide the commit at which they were built

[abailly-iohk]

Running recent static binary, I got the following:

$ ./hydra-node  --version
0.10.0

which is not very informative and does not help in checking whether or not I am running the expected version of the node, and at which commit this version was built.

I would expect something like

$ ./hydra-node  --version
0.10.0-342137bcd

[ch1bo]

There was a related red bin item with the observation this is coming from the nix build which does not use git describe output:

$ cabal build hydra-node
$ cabal exec hydra-node -- --version
0.8.0-175-g4cf4155cf

$ nix build -f release.nix hydra-node
$ result/bin/hydra-node --version    
0.9.0

[abailly-iohk]

cardano-node is patching the executable's binary to add the version, apparently: https://github.com/input-output-hk/cardano-node/blob/master/nix/haskell.nix#L297-L324

[ch1bo]

May I suggest that we also try to use the git describe output in the nix build? Would your expectation be met with something like

$ ./hydra-node --version
0.9.0-g123-342137bcd

Which includes the git revision 342137bcd, but also additional information that the last release was 0.9.0 and this is some 123 commits ahead.

[abailly-iohk]

The cardano-node uses a complexe machinery to patch the binaries, which I find somewhat annoying. I have started a branch that instead tries to read the needed revision (or description) from an environment variable that can be set for the underlying builder to use. The problem is that I don't know how to pass that environment variable to the nix build...
Any idea @ch1bo?

Note: I am aware this makes nix build non hermetic. I can resort to the node's solution (patching binaries) if need be.

[abailly-iohk]

@pgrange Suggested we could also patch the source code before the build which is a sed oneliner and friendlier to nix perhaps?

[pgrange]

Not proud of it but relying on this trick when releasing another project:

• the source code contains the version: https://github.com/pgrange/bash_unit/blob/master/bash_unit#L19
• the release script overrides the value: https://github.com/pgrange/bash_unit/blob/master/release#L51

[abailly-iohk]

It would be great if we could use the version field of the cabal package description but of course, cabal does not allow that: https://cabal.readthedocs.io/en/3.4/cabal-package.html#pkg-field-version
@pgrange The problem with modifying sources is that nix flake is sensitive to uncommitted changes I think. I think the least ugly solution is to patch the binary (note that nix already does this for setting dynamic libraries path to /nix/store)

[ch1bo]

It would be great if we could use the version field of the cabal package

IIRC we do use the version from the .cabal file as a fallback. It's the 0.10.0 from your original post where we did not (yet) git tag 0.10.0.

[abailly-iohk]

@ch1bo Yes, but my point was to suggest we could use the version field to add the SHA information on the fly when building (eg. patching source)

[abailly-iohk]

I think I will go for a simple solution: Generate a file containing the data and use file-embed to inject the content of this file, if it exists, in the executable.