Learn more about these different git repos.
Other Git URLs
It would be great if we could specify that a pungi run was intentionally going to be a nightly run in the pungi config rather than having to specify it on the command line every time it gets run (like here).
The idea would be that there is a config option that could be set in the config that could then be overidden by the CLI. I'm not sure exactly what the option name would be. Maybe compose_type. so we could set compose_type=nightly in the config and also override on the cli --compose_type=production, which would most likely deprecate the existing cli options like --nightly.
compose_type
compose_type=nightly
--compose_type=production
--nightly
there is no reason why the exact same config can't be used fro nightly and production composes. we only use separate configs today due to different articafts being delivered by the different composes.
100% agree. The fact that this config option would be useful isn't related to that fact though.
Basically the need for this came up during a discussion about bodhi+pungi integration. In an initial step we would possibly start creating repos/ostrees/isos/cloudimages all during the same pungi run when we run bodhi against f26-updates. We would use a pungi config for that.
f26-updates
We would use a separate pungi config for f26-updates-testing and we may in the future decide to add image creation to this pungi run as well. If we did that then it would be useful to embed the --nightly type into the config itself rather than having to add it as an argument to the place where we invoke pungi on the command line. i.e. let's update the config with more information that switching around the command line. This all assumes that for updates-testing we'd prefer to have the images created be denoted as nighly rather than prod.
f26-updates-testing
This config could easily be overridden by a CLI option as stated in the original description.
Proposed fix in #717.
Metadata Update from @lsedlar: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Metadata Update from @lsedlar: - Issue tagged with: 4.1.19
Login to comment on this ticket.