Learn more about these different git repos.
Other Git URLs
Atomic Reactor will take care of auto increment the release value, based on previous build found in Koji, if one is not provided via the plugin bump_release.
There's a bug in the implementation of this feature in pungi, in which the package version is not accounted for.
Pungi should not attempt to implement this feature, and simply hand off to osbs.
As a workaround, the "release" key should be completely omitted from osbs settings, as setting it to None would trigger the broken behavior. This is also the expected usage once the dynamic release feature is removed from Pungi.
BTW, there seems to already exist a unit test for verifying correct behavior when "release" key is missing from osbs settings.
Pungi should be setting the release and version values to ensure consistency across the compose
The release value that is auto incremented by Atomic Reactor will be available in the actual koji build, which is already retrieved by pungi here and set in the metadata.
Given this, Pungi can still ensure consistency across the compose, no?
The consistency Dennis talks about is in a situation when the compose builds multiple images (with different names), they should all have the same version and the same release. For live media in Fedora, that was achieved by putting the value directly in the config for the final release.
If the release value is always generated outside of Pungi, this level of control will be lost.
I'm perfectly ok with removing the logic for finding next release value. That would leave only two options: if the config does not specify the release, Atomic Reactor will pick one; if the config specifies a release value, it will be used.
Do you want to remove the second option as well? Are there plans in OSBS world to not allow specifying release at all?
Yes, we should remove the option of specifying the release number explicitly as Atomic Reactor won't honor it. It'll either read it from the release label in the Dockerfile, or will auto increment it from Koji.
Can the multiple images scenario still be achieved by setting the release label in the Dockerfile? The downside is that this would require a commit with the Dockerfile changes.
This is not a scenario we had taken into account before.
@lsedlar and do we know if this scenario is something we need to support internally today or is this only upstream?
@acarter I have not seen this requirement internally. I would argue it is not a very big issue even in Fedora, but that would be for @ausil to confirm.
It is currently done for live media, but RPMs obviously have different versions and releases. While having the consistency for the images is nice, it does not seem super important (given that the actual values are available in metadata).
The patch removing the option from Pungi is available in #349.
@lsedlar changed the status to Fixed
Fixed
Login to comment on this ticket.