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)

• 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)

• RFE: could the testing system also send a fedmsg for builds that will not be tested, so in case there is an outage, the client does not assume builds go can while in fact they aren't any testing being done. --Pingou (talk) 18:38, 27 April 2017 (UTC)