Project

General

Profile

Bug #9542

Support rebuilds of plugins instead of retagging over major releases

Added by Dominic Cleal over 7 years ago. Updated almost 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
RPMs
Target version:
-
Difficulty:
Triaged:
No
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:

Description

Currently when we build a new plugin release, e.g. foreman_docker 1.2.0, we traditionally build it in the nightly plugin tags (the rpm/develop packaging branch, the foreman-plugins-nightly-* Koji build targets) and then retag it into older releases. This usually works because there's not much in the plugin build proecss that depends on the Foreman version (even asset precompilation).

With #4478, we changed a runtime aspect of the RPM build - the %posttrans scriptlet now calls rake apipie:cache:index rather than apipie:cache. Running that on Foreman 1.7 won't work, it's 1.8 only, so the spec file needs branching.

We can build from older rpm/* branches easily enough, but when building the same source version (e.g. 1.2.0) for both rpm/1.7 and rpm/develop, it's problematic as the git/tito tags will collide (rubygem-foreman_docker-1.2.0-1) and so will the NEVRA in Koji (which has to be unique).

We can hack around this by say building -1 in rpm/1.7 and -2 in rpm/develop, but it isn't pretty, and could lead to mistakes - the release field should already ascend through releases so the RPM is upgraded when a user upgrades between major releases, so can't be -2 in rpm/1.7 and -1 in rpm/develop.

What might neatly solve it is putting the Foreman version into the release field, like a dist tag. I did this manually in https://github.com/theforeman/foreman-packaging/commit/86c6f785 but if we could automatically define a %{foreman_dist} in the build environment (and tito's configuration) then this might be more reliable.

History

#1 Updated by Dominic Cleal over 7 years ago

We've been very lucky that we haven't hit this before now actually. I have also been expecting to hit it a lot after we do #4841 too, as that is going to introduce runtime changes into every package (ruby193 vs tfm in package requires).

#2 Updated by Dominic Cleal almost 7 years ago

  • Status changed from New to Resolved

We're doing this now via the %foremandist macro.

Also available in: Atom PDF