Add CLI git hash

[hu55a1n1]

Closes: #1094

Description

Export a env var (i.e. HERMES_VERSION) from build.rs and use it as the CLI's version string.
The newer version string is a valid semver string of the form -> <pkg-version>+<git-branch>-<git commit hash>. There's also an optional suffix -dirty which is added if the git repo is dirty. e.g. -> 0.4.0+cli-git-hash-760270a8-dirty

---

For contributor use:

• Updated the Unreleased section of CHANGELOG.md with the issue.
• If applicable: Unit tests written, added test to CI.
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Updated relevant documentation (docs/) and code comments.
• Re-reviewed Files changed in the Github PR explorer.

[romac]

Very nice, thanks @hu55a1n1!

One request: is there a way we can ensure that binaries built on CI and uploaded to the GitHub release show just the version without the +branch-commit[-dirty] suffix?

[hu55a1n1]

One request: is there a way we can ensure that binaries built on CI and uploaded to the GitHub release show just the version without the +branch-commit[-dirty] suffix?

Thanks for reviewing the PR @romac!
I have been thinking about how to achieve that. Do you know if there's an env variable that the CI sets or some other way that I can use to figure out if the build script is running on the CI?

Otherwise, is it an option to change the regex in acceptance.rs to version meta?

fn start_no_args() {
    // ...
    let mut runner = RUNNER.clone();
    let mut cmd = runner.capture_stdout().run();
    cmd.stdout().expect_regex(
        format!(
            "^[^ ]*{} {}", // <-------------------------- remove the trailing `$`?
            env!("CARGO_PKG_NAME"),
            env!("CARGO_PKG_VERSION")
        )
        .as_str(),
    );
    // ...
}

[romac]

One request: is there a way we can ensure that binaries built on CI and uploaded to the GitHub release show just the version without the +branch-commit[-dirty] suffix?

Thanks for reviewing the PR @romac!
I have been thinking about how to achieve that. Do you know if there's an env variable that the CI sets or some other way that I can use to figure out if the build script is running on the CI?

Otherwise, is it an option to change the regex in acceptance.rs to version meta?

fn start_no_args() {
    // ...
    let mut runner = RUNNER.clone();
    let mut cmd = runner.capture_stdout().run();
    cmd.stdout().expect_regex(
        format!(
            "^[^ ]*{} {}", // <-------------------------- remove the trailing `$`?
            env!("CARGO_PKG_NAME"),
            env!("CARGO_PKG_VERSION")
        )
        .as_str(),
    );
    // ...
}

Yes, I actually did that in d3c5360, which has fixed the test.

But now the CI is still broken because Rust 1.53 was just released, and comes with new clippy lints. I think we can disregard these failures for now. I will fix them in a separate PR.

[romac]

Do you know if there's an env variable that the CI sets or some other way that I can use to figure out if the build script is running on the CI?

Looks like there's a bunch of them, not sure which one we should use. Perhaps we can check for GITHUB_JOB == "create-release"?

[romac]

But now the CI is still broken because Rust 1.53 was just released, and comes with new clippy lints. I think we can disregard these failures for now. I will fix them in a separate PR.

Should be good now, merged #1102 and merged master here.

[hu55a1n1]

I just noticed that the new version doesn't appear for help subcommands like hermes tx help. The reason is that there's a blanket impl<C> Command for Help<C> where C: Command, and due to the way gumdrop deals with help, this would mean that we would have to write quite a lot of impls for helps manually instead of deriving them.
I think this was the reason the build script overwrites the CARGO_PKG_NAME instead of trying to change Command impls. I think that is the best solution to modify the version as well, i.e. overwrite CARGO_PKG_VERSION with a valid semver.
If there is no objection, I would like to implement the git hash support in a similar fashion. 🙂

[hu55a1n1]

Linking #590 here, because it describes the problem in more detail. Although here, the chances of breaking cargo workflow are quite low since we're not overwriting the version for CI builds.

[romac]

@hu55a1n1 What's the status on this PR?

[adizere]

Tagged with "backburner" until Shoaib returns from holidays to look at this again.

[hu55a1n1]

@hu55a1n1 What's the status on this PR?

The acceptance test for the CLI was failing because it didn't escape regular expression meta characters in the CARGO_PKG_VERSION since this wasn't expected before. I think it is fixed now. 👍

[adizere]

Nice work, this is going to be very useful!