Add Zarf Version to CLI options

[YrrepNoj]

Since the zarf binary can be passed around easily, it would be useful for people who know what version of the binary they have. zarf version will now display the latest tag and the specific commit sha it was built with.

This also updates the Makefile to store the version as a string within a variable.

[RothAndrew]

Taking a look. In the meantime can you:

• Link the PR to the issue
• Move the issue to "Now" in the roadmap

[RothAndrew]

Should we update the General CLI E2E test to test this new command?

[jeff-mccoy]

Should we update the General CLI E2E test to test this new command?

Yes I think we should add a quick test for this to the E2E. Also curious if we want to use this version info at all, like embedded into the packaging on package create. This would make it easy later on to notify on version mismatches or even auto-embedding the zarf binary into a package for updates.

[YrrepNoj]

Should we update the General CLI E2E test to test this new command?

Yes I think we should add a quick test for this to the E2E. Also curious if we want to use this version info at all, like embedded into the packaging on package create. This would make it easy later on to notify on version mismatches or even auto-embedding the zarf binary into a package for updates.

Just to make sure I'm reading this correct. I don't think you're saying "Is this really the version number we want to use" but I'm not entirely sure what you're saying.

Are you suggesting we also add the zarf version into a yaml that gets packaged into the SOME_PACKAGE.tar.zst?

[jeff-mccoy]

Should we update the General CLI E2E test to test this new command?

Yes I think we should add a quick test for this to the E2E. Also curious if we want to use this version info at all, like embedded into the packaging on package create. This would make it easy later on to notify on version mismatches or even auto-embedding the zarf binary into a package for updates.

Just to make sure I'm reading this correct. I don't think you're saying "Is this really the version number we want to use" but I'm not entirely sure what you're saying.

Are you suggesting we also add the zarf version into a yaml that gets packaged into the SOME_PACKAGE.tar.zst?

Yeah that's just bad wording, sorry. What I was trying to say was. Is there some place we'd like to actually use this besides a user manually running zarf version. E.g. we could auto-inject the zarf version used to create the package under:

type ZarfBuildData struct {
	Terminal  string `yaml:"terminal"`
	User      string `yaml:"user"`
	Timestamp string `yaml:"timestamp"`
	// Version of zarf used to create the zarf package
	Version   string `yaml:"string"`
}

We could then (maybe in a new issue/PR) add a feature to check this version in the package against the current zarf binary version and warn users on errors.

[jeff-mccoy]

This should be correct. During build you will have the git repo and pass the build flag with the tag to make the version. The binary copying will then already have the compiled build arg injected to show the version.

[YrrepNoj]

/test all

[YrrepNoj]

/test all

[YrrepNoj]

/test all

[YrrepNoj]

/test all

[jeff-mccoy]

Great work, thanks for adding the e2e and struct change

[RothAndrew]

See above comment

[RothAndrew]

/test all

[jeff-mccoy]

Yeah I missed the space in the test, but agree the style for buildtime injection is a good pattern as when we cut a tag it will also reflect that in the resultant artifact.