Zebra: Use git metadata and platform info in Zebra

[teor2345]

When we get bug reports about zebrad, it would be helpful to have exact version and platform information.

vergen crate

We could use vergen's:

• [x] VERGEN_SHA_SHORT
• [ ] VERGEN_COMMIT_DATE
• [ ] VERGEN_TARGET_TRIPLE
• [ ] VERGEN_HOST_TRIPLE - maybe, could break reproducible builds?
• [ ] VERGEN_RUSTC_SEMVER
• [ ] VERGEN_RUSTC_CHANNEL
• [ ] VERGEN_BRANCH
• [ ] VERGEN_SEMVER (from git describe)

See https://docs.rs/vergen/3.2.0/vergen/index.html

We'd also want to set:

• [x] vergen::ConstantsFlags::REBUILD_ON_HEAD_CHANGE, so that every build gets the latest commit hash

See https://docs.rs/vergen/3.2.0/vergen/struct.ConstantsFlags.html#associatedconstant.REBUILD_ON_HEAD_CHANGE

Google Cloud

When building in Google Cloud, we can use:

• [x] SHORT_SHA

See:
https://cloud.google.com/cloud-build/docs/configuring-builds/substitute-variable-values#using_default_substitutions

Implementation

Git version

Ideally, we should have the git version (SHORT_SHA or VERGEN_SHA_SHORT) appear in:

• [ ] the Zcash network protocol platform string - optional
  
  
  
  • https://github.com/ZcashFoundation/zebra/blob/main/zebra-network/src/constants.rs#L61
  
  
• [x] an info-level log message at startup - #1410
  
  
  
  • https://github.com/ZcashFoundation/zebra/blob/main/zebrad/src/application.rs
  
  
• [x] error and warning logs - #1410
• [x] the panic log metadata - #1410

Other version info

We'd also like:

• [ ] VERGEN_SEMVER or CARGO_PKG_VERSION + git_commit
  
  
  
  • VERGEN_SEMVER: git describe, contains the git tag name and number of following commits
  
  
  • CARGO_PKG_VERSION + git_commit: contains the package version from Cargo.toml, if git is not available at build time, plus the git commit from vergen or google cloud
  
  

To appear in:

• [ ] the zebra-network user-agent string
  
  
  
  • https://github.com/ZcashFoundation/zebra/blob/main/zebra-network/src/constants.rs#L64
  
  
  • provide a zebrad user-agent for zebrad, and another user-agent for other zebra-network users:
  
  
  • [ ] add an app user-agent argument to the init function
  
  
  • [ ] also provide a zebra-network user-agent, using the crate version from a zebra-network vergen build script
  
  
  • [ ] use the Bitcoin user-agent syntax: https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
  
  

Detailed version metadata

We'd also like:

• [ ] VERGEN_COMMIT_DATE
• [ ] VERGEN_TARGET_TRIPLE
• [ ] VERGEN_HOST_TRIPLE
• [ ] VERGEN_RUSTC_SEMVER
• [ ] VERGEN_RUSTC_CHANNEL
• [ ] VERGEN_BRANCH
• [ ] VERGEN_SEMVER or CARGO_PKG_VERSION + git_commit

To appear in:

• [ ] the zebrad version command
  
  
  
  • https://github.com/ZcashFoundation/zebra/blob/main/zebrad/src/commands/version.rs
  
  
  • might be fixed by changing https://github.com/ZcashFoundation/zebra/blob/main/zebrad/src/components/tracing/component.rs#L80
  
  
• [ ] the zebrad version in the help message (when you run zebrad without any arguments) - optional
• [ ] an info-level log message at startup
• [ ] the panic log panic_section
• [ ] the panic log URL add_issue_metadata

Alternatives

I had a look at vergen's other build time info, and I don't think we want it:

• FROM_CARGO_PACKAGE is redundant with ZebraCmd::version()
• the build time variables would break reproducible builds, because they depend on the build machine's clock

I don't think we'll want the other Google Cloud variables either.

Related Issues

https://github.com/ZcashFoundation/zebra/pull/1410#issuecomment-737533655

[hdevalence]

Knowing the exact commit SHA seems like it would be helpful for debugging builds from git, but would we still want it for tagged releases, where the semver string's git tag is enough to canonically identify the exact version? Working with semver strings seems a lot more user-friendly than working with commit hashes.

[yaahc]

If this information is going to be in a lot of our log lines I'd want to try to keep it as minimal as possible. Ideally just the SHA, and not the commit date, because that can easily be determined via the sha. Also, I want to make sure we label it in the output so its clear that the sha is a git commit sha.

I've worked with a codebase that logged a ton of extra context that was occasionally relevant like pid and thread ids, and various identifiers for pieces of the system where none of the numbers were labeled and you just had to know that the 1st one was PID and the 3rd one was an RSDID (or did I get that backwards?) and it is hell to keep everything straight, along with the fact that it significantly increased the verbosity of our logs.

[teor2345]

I think the standard format is something like:

• git-(short sha)-(optional "extra")

For example:
git-abcdef
git-abcdef-extra (with uncommitted changes)

I've seen users make all sorts of changes, and then build in release mode. Fixing those bugs was terribly confusing, because we didn't know what code we were actually working with.

[yaahc]

Sounds good, how do you feel about replacing the git sha with a tag if we're on a tagged release? I'm not sure if vergen can handle that but if so that might be a nice QoL feature.

[dconnolly]

Sounds good, how do you feel about replacing the git sha with a tag if we're on a tagged release? I'm not sure if vergen can handle that but if so that might be a nice QoL feature.

Tags can be moved around (_can_ be, we _shouldn't_ move them around, but it can happen) so I would make the short 7 char commit sha always be included, and the semver of zebrad (which _should_ match a tag on the commit when released).

[hdevalence]

I think we should close this for now to stay focused and revisit it if we ever get a confusing bug report.

[teor2345]

Reopening this issue because:

• we wanted the commit hash in the report metadata as part of #1072
• I've wanted the commit hash in the zebrad help message, so I could add the exact commit to my Zebra bug reports

[teor2345]

I've simplified the issue, and added the target triple, because it would actually be useful in bug reports from users.