Closed bgurney-rh closed 1 year ago
Step 1: Add an option --pre-release-suffix
that allows us to pass an arbitrary string to incorporate into the release string. This is not the final step, but a useful intermediary. We would make sure that the value of "--pre-release-suffix" was properly appended to the name of every artifact that was generated. The script should print out the release version including the suffix once it completes.
Step 2: Add another option, --calculate-pre-release-suffix
. This option is exclusive with --pre-release-suffix
. When it is set, then the suffix is calculated and namespace.pre_release_suffix
is set to the calculated value.
Step 3: Use the --calculated-pre-release-suffix
option in the mock build test scripts. These can pick up the full release version string from the create_artifacts.py script output.
These steps should complete the whole task.
The --calculate-pre-release-suffix
step (2) is still a good idea, but since everything is, I believe, working fine now, it's just not so urgent.
We now calculate the pre-release suffix by default in create_artifacts.py if --pre-release is set, and we have yet to find a reason not to do that, so closing.
I would like to set up a way to periodically build pre-release Stratis packages for testing, via the "mockbuild" scripts that act as a front-end for "mock --buildsrc", while ensuring that I can label and identify the version of code packaged. Can we add an option to "create_stratisd_artifacts.py" and "create_stratis_cli_artifacts.py" to add an additional suffix to the "Version" string of the source artifacts?
I had an idea to use a suffix to the "Version" string, which would contain the "~" character (ensuring that this package would be "earlier" than the official release), followed by an 8-digit date code, and the git hash of the head revision being built. However, after some experimentation, I found that I can't simply append onto the "Version:" field of the package's ".spec" file; I would need to rename the base directory inside the source tar file (and in the case of stratisd, the vendor tar file, and the crate).
For example, "stratisd-3.2.0-77.el9" would become "stratisd-3.2.0~20220705gitaef7f087-77.el9". (I would want to maintain the phony "Release" value of 77, along with the warning in the spec file that the package should not be used in production.) This way, a tester could then switch to the stratisd repository, and type "git show aef7f087", and be able to see the head commit from the repository used for building the package (since it won't be possible to run "git show" inside the source RPM contents).