Talk:FedoraAtomicCI/pipeline

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)
• 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)
  • A: By modifying the tests/ directory and enabling/disabling tests. --Stefw (talk) 09:37, 26 April 2017 (UTC)
  • +1 --Alivigni (talk) 13:15, 26 April 2017 (UTC)
    • So there is no WARNING state? It's either on or off. Just to be sure we're 100% clear on this, I know the kernel folks have tests that are allowed to fail but still being run and considered informative. --Pingou (talk) 09:58, 26 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)