Embed the git commit in fj-app's version number

[Michael-F-Bryan]

Fixes #850.

The version number for an official build will look something like this:

$ FJ_OFFICIAL_RELEASE=1 cargo run --quiet -- --version
fj-app 0.8.0 (66de87d0)

Not having the $FJ_OFFICIAL_RELEASE variable set will add unreleased to the version number, and having a dirty git tree will add a -modified suffix to the commit hash.

$ cargo run --quiet -- --version
fj-app 0.8.0 (4ef5109e-modified, unreleased)

When git doesn't start (i.e. because it's not installed), we silently leave out the commit hash. This is a bit of an edge case, but I've found it often happens when you are building an app inside a Docker container or a cargo install from crates.io because you typically don't have access to the repo's .git/ folder.

We could use something like vergen or build_info to get more comprehensive output similar to rustc --version --verbose, but that felt like overkill and would have an impact on compile times.

[hannobraun]

Thank you, @Michael-F-Bryan! Looks good overall, but I found some potential issues. I left comments.

[hannobraun]

I believe this is incorrect. The CD workflow is run (and builds binaries for) every push to main. If a release is detected, those binaries are re-used for the actual release.

Note the Operator | Deduce step, which detects whether we're dealing with a release, or a regular push to main, and the if: ${{ steps.release.outputs.release-detected == 'true' }} bits that use that step's output.

Not sure how good your grasp on GitHub Actions is. We might need @hendrikmaus to help figure this out.

If this turns into a problem, we could consider removing the per-push-to-main build, and only build binaries for the release. I'm not sure how useful those per-push binaries are anymore, with weekly releases. Thoughts?

[Michael-F-Bryan]

Ahh, I just had a deeper look into how the release job works, and it seems like every push to main generates its own compiled binaries, but they only get promoted to a proper release if the "release operator" says so.

That makes things more complicated because fj-app won't know at compile time whether it is a proper release (the release job depends on binaries, but Binaries | Compile would need to know steps.release.outputs.release-detected - which is a dependency cycle).

[hannobraun]

Thank you, @Michael-F-Bryan, the new commits look good!

The only remaining problem is that all CD binaries are blessed as release binaries, not just the actual release ones.

Ideas for addressing this:

1. Fix this problem by cleverly changing the CD workflow.
2. Fix this problem less cleverly: only build binaries for actual releases.
3. Ignore the problem, merge this PR, open an issue.

The more I'm thinking about this, the more I'm leaning towards solution 3. This is already a nice improvement, and there's no need to hold it back because of one edge case.

I'll think some more. I expect to make a decision later today.

[hannobraun]

I've decided to just merge this pull request. I'll open a new issue about the wrongly labeled binaries.

[hannobraun]

I've opened #883.