From Fedora Project Wiki
Questions
- Is the long term plan to make the compose in Jenkins or here as well is it a temporary approach? --Pingou (talk) 14:39, 25 April 2017 (UTC)
- Is there plans on re-using the exact same tools for these steps as in prod? (pungi?) --Pingou (talk) 14:39, 25 April 2017 (UTC)
- A: One of the goals of this effort is to be able to learn from it and modify/replace parts that don't work. Implementation details like this should not be set in stone. But we also don't need to have a plan for replacing each component before we know how they fulfill their use case. This also means that inter-component communication/interface mechanisms should be general enough to iterate on the implementation behind them. --Stefw (talk) 09:37, 26 April 2017 (UTC)
- A: It was stated directly we will be using Openshift and Jenkins for this effort so I believe this is a long-term solution. --Alivigni (talk) 13:15, 26 April 2017 (UTC)
- But this effort has always been presented as a prototype, my concern here is about: if this prototype is successful, then what are the plans? To stick with Jenkins and Openshift?
- As I understand it, a precept of the CI pipeline is that the build that's tested is the build that should be shipped. Has RCM/Fedora releng been consulted about not using koji builds for shipping? For a prototype this isn't necessary but for a long-term solution it's a hard requirement. --pfrields (talk) 19:01, 26 April 2017 (UTC)
- How will we map dist-git changes to bodhi updates? --Pingou (talk) 14:39, 25 April 2017 (UTC)
- Does the NVR help us here? I experienced Bodhi refuses to create an update if it does not find an appropriate NVR in Koji. --Stefw (talk) 09:37, 26 April 2017 (UTC)
- It would but the NVR uniquess is enforced after the build not in dist-git. So we could have: packager A does an update of the package, builds it, submits it to Bodhi, packager B touches the spec file, without touching the version or release tags and somehow breaks something. We're now blocking an update in Bodhi due to a change that isn't related to this update. --Pingou (talk) 09:58, 26 April 2017 (UTC)
- Does the NVR help us here? I experienced Bodhi refuses to create an update if it does not find an appropriate NVR in Koji. --Stefw (talk) 09:37, 26 April 2017 (UTC)
- How is the packager going to choose which test/test-suite gate the package? By turning them on/off or would there be a way to flag a test as: "allowed to fail"? --Pingou (talk) 14:39, 25 April 2017 (UTC)
- Stage 2 says: Build result on the fedmsg bus will be plumbed through to bodhi via resultsDB, but there potentially no bodhi update to report to here since not all dist-git commits are followed by a build and not all build are submitted to be updates. --Pingou (talk) 07:03, 26 April 2017 (UTC)
- How many message will be sent for each testing steps? 1 message pass/fail for the entire test run, or 1 per test in the run? (So is it 1 message just returning the boolean returned by ansible or 1 message per item tested during the ansible run) -- So client side, do we have to watch for 1 message or multiple? --Pingou (talk) 18:23, 27 April 2017 (UTC)