-
-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement fj-app --version
#850
Comments
Clap has the long version for this and a convenience Macro to help setting it during compile time https://docs.rs/clap/latest/clap/builder/struct.App.html#method.long_version To figure out if we are building a release or not, release-operator's deduce step must run first. I would propose to add a job that runs before the binary build job. It only runs the deduce command and shares the outcome as an output with the remainder of the pipeline. Then the binary builder job can wait for that and use the output. And after building the binaries, the remaining release-operator job also runs conditionally on the output from the first job that ran the deduce command. I don't think you need a build.rs or anything more than Clap and a bit of pipeline step reordering. |
Thank you for the insight, @hendrikmaus! I've opened #883 (probably while you were typing this 😄), where I suggest something very similar to the reordering you suggest here. Regarding using Clap's capabilities instead of a |
On second thought, we might want to use the version in other parts of the UI, not just as a response to In any case, it might be a disadvantage to rely on Clap for this capability. Unless the current |
fj-app
should have a--version
argument that returns the current version. Given that we release weekly, it would be great if this version wouldn't have to be updated manually. This should be straight-forward to achieve: https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-cratesWhile I would definitely merge a pull request that implements this straight-forward version, it would be great if there was some additional nuance:
I assume that both of those can be achieved by creating the version string in a build script, and passing it to the
fj-app
source code as an environment variable. The release automation could use an environment variable to signal the build script whether this is an official release build.The text was updated successfully, but these errors were encountered: