Is there a way to include the (git)commit hash in the building crate for debug builds only?

I wonder whether there is a convenient way to include the git commit hash into the debug build of a crate, but not into the release build.

My attempt on solving this is: this build script and this helper macro.

Maybe there’s a more convenient way? Cargo does not include this information as environment variable itself, as far as I see? Maybe that’s an idea for a feature in cargo?

1 Like setting an env var and env!() in the code looks right.


try crate built:


built sounds awesome, thanks!

Probably the wrong place to ask, but I was also interested in having a git commit hash in my version info of my executables and started using the built create, but I ran into problems regarding the GIT_COMMIT_HASH. If I just add:

+pub mod built_info {                                                                                   
+    include!(concat!(env!("OUT_DIR"), "/"));                                                   
+    println!(                                                                                          
+        "This is version {}, built for {} by {}.\n",                                                   
+        built_info::PKG_VERSION,                                                                       
+        built_info::TARGET,                                                                            
+        built_info::RUSTC_VERSION                                                                      
+    );                                                                                                 

I get a message like this:

This is version 0.8.3, built for x86_64-unknown-linux-gnu by rustc 1.48.0 (7eac88abb 2020-11-16).

But I can't use this additional line:

println!("I was built from commit {}.", built_info::GIT_COMMIT_HASH);

It fails with:

error[E0425]: cannot find value `GIT_COMMIT_HASH` in module `built_info`
   --> src/bin/
866 |     println!("I was built from commit {}.", built_info::GIT_COMMIT_HASH);
    |                                                         ^^^^^^^^^^^^^^^ not found in `built_info`

I kind of figured (from the example project) that I should add a feature git2 to my Cargo.toml:

built = { version = "0.4.4", features = ["git2"] }

But this fails with:

cargo test --release --no-default-features
error: failed to select a version for `cc`.
    ... required by package `libgit2-sys v0.12.0+0.99.0`
    ... which is depended on by `git2 v0.13.0`
    ... which is depended on by `built v0.4.4`
    ... which is depended on by `pbrt v0.8.3 (/home/jan/git/github/rs_pbrt)`
versions that meet the requirements `^1.0.42` are: 1.0.65, 1.0.64, 1.0.63, 1.0.62, 1.0.61, 1.0.60, 1.0.59, 1.0.58, 1.0.57, 1.0.56, 1.0.55, 1.0.54, 1.0.53, 1.0.52, 1.0.51, 1.0.50, 1.0.49, 1.0.48, 1.0.47, 1.0.46, 1.0.45, 1.0.44, 1.0.43, 1.0.42

all possible versions conflict with previously selected packages.

  previously selected package `cc v1.0.37`
    ... which is depended on by `backtrace-sys v0.1.30`
    ... which is depended on by `backtrace v0.3.32`
    ... which is depended on by `error-chain v0.12.1`
    ... which is depended on by `cargo_metadata v0.6.4`
    ... which is depended on by `skeptic v0.13.4`
    ... which is depended on by `ply-rs v0.1.3`
    ... which is depended on by `pbrt v0.8.3 (/home/jan/git/github/rs_pbrt)`

failed to select a version for `cc` which could resolve this conflict
Makefile:28: recipe for target 'without-exr' failed
make: *** [without-exr] Error 101

Any help with that (or pointing me to a better place to ask) would be appreciated! Thanks.

From the author of the built crate:

the problem has little to do with built or GIT_COMMIT_HASH. The package ply-rs v0.1.3 in your dependency-tree pulls in skeptic ^0.13.4, which is almost two years old and causes a very old version of cc to get pulled in, which ultimately conflicts with the version pulled in via libgit2-sys.
Maybe you can get the ply-rs author to bump the package's dependencies. Its dependency on skeptic ^0.13.4 most likely should simply read ^0.13 (which covers 0.13.5, resolving the conflicting version of cc).

So, that's what I tried to do. I contacted the author of ply-rs and asked him for that change ... Let's see if and what he will answer ...

I used to do someting similar, but found that most variants could be (accidentally) fooled while doing strange stuff in my local environment. So now I tend to set an environment variable $CI_VERSION or similar in my continous integration build scripts, and use it like:

let version = option_env!("CI_VERSION").unwrap_or("unknown");
1 Like

@kaj Thanks, I think a simple environment variable with the output of git describe --tags is all I need for now. That allows all executables to print that info (or unknown as you suggested).