Foreman » Packaging

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.