Support pre-release versions in sync_release #2149
Conversation
|
Build failed. ✔️ pre-commit SUCCESS in 1m 48s |
|
/packit build |
|
/packit-stg build |
|
recheck |
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 48s |
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 47s |
Thanks. No, I haven't, but that's a good idea. |
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 59s |
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 52s |
Prepare spec files and configure Packit for pre-releases Related to packit/packit#2149. Reviewed-by: Laura Barcziová
|
@nforro Podman's RCs are tagged |
|
Thanks for the feedback!
Yes.
How soon? I'll try to get this PR merged this week so it can be deployed to production next Tuesday, would that be soon enough? |
Ack.
Good to know, thanks.
We'll be likely releasing sometime next week so this should be fine. I can get the changes in to podman's spec file this week itself. |
The `version_no_tilde` rpm macro correctly handles both `vX.Y.Z` and `vX.Y.Z-rcN` git tags. Using this macro instead of `version` will soon allow Packit to handle RC builds correctly. Accompanying change in Packit to land soon: packit/packit#2149 Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
The `version_no_tilde` rpm macro correctly handles both `vX.Y.Z` and `vX.Y.Z-rcN` git tags. Using this macro instead of `version` will soon allow Packit to handle RC builds correctly. Accompanying change in Packit to land soon: packit/packit#2149 [NO NEW TESTS NEEDED] Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
|
I've factored out the pre-release handling code to a separate function in order to be able to use it in the prepare-release action. |
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 52s |
|
/packit rebuild-failed |
|
/packit-stg rebuild-failed |
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 50s |
Release 0.24.1-rc1 I've updated the prepare-release action, but it won't work until packit/packit#2149 is merged and a new Packit image is built, so I decided to do this pre-release manually in order to test the mentioned Packit PR. Reviewed-by: Maja Massarini
|
Build succeeded. ✔️ pre-commit SUCCESS in 1m 50s |
|
Build failed. ✔️ pre-commit SUCCESS in 1m 44s |
Implement updating version with support for pre-releases Moved the implementation from packit/packit#2149 here and improved update_value(). Related to packit/packit#2013. Merge before packit/packit#2149. RELEASE NOTES BEGIN There is a new method, Specfile.update_version(), that allows updating spec file version even if it is a pre-release. RELEASE NOTES END Reviewed-by: František Lachman <flachman@redhat.com> Reviewed-by: Nikola Forró
|
Build failed. ✔️ pre-commit SUCCESS in 1m 44s |
Signed-off-by: Nikola Forró <nforro@redhat.com>
|
Build failed. ✔️ pre-commit SUCCESS in 1m 54s |
|
@lsm5 This is now in production, but I can see that podman 4.8.0-rc1 was released yesterday, which was unfortunately too soon and propose_downstream failed: https://github.com/containers/podman/runs/18862561453 |
ugh whoops. Seeing this only after I manually bumped podman rpm. Never mind, there's always another RC down the line :) . Thanks a lot! |
There are two ways how to support pre-releases in a spec file.
The simpler way relies on the
%version_no_tildemacro fromrust-srpm-macros(not present on EL < 9) that converts a pre-release version with~back to upstream version. An optional argument defines upstream delimiter that defaults to-.Here is an example of a spec file using this macro:
If upstream version doesn't have a delimiter, for example
3.28.0b5, you can use%{version_no_tilde %{quote:%nil}}.The second, more complex way requires you to define a macro, typically called
prereleaseorprerel, and package version (value of theVersiontag) and upstream version are constructed depending on whether it is defined or commented out.Here is an example of such a spec file:
And a little more complex example that achieves the same (but this time there is no delimiter in upstream version and tarball URL is slightly different):
Packit supports both ways. There is a new config option
prerelease_suffix_patternthat defines a regex that is used to determine if a version is a pre-release or not. It defaults to([.\-_~^]?)(alpha|beta|rc|pre(view)?)([.\-_]?\d+)?and you can adjust it if your project uses a different versioning scheme or undefine it to opt-out from pre-release processing. The first capturing group of the regex should capture the delimiter (and can be empty if there is none).If a pre-release is detected, the delimiter is replaced with
~. You can also configure theprerelease_suffix_macrooption to correspond to a pre-release macro in your spec file and this macro will be commented out or uncommented accordingly.TODO:
Merge after packit/specfile#317.
Fixes #2013.
RELEASE NOTES BEGIN
Packit now supports pre-release version in
propose_downstreamandpull_from_upstream. A spec file update might be required, see the documentation for more details.RELEASE NOTES END