On 20.04.2017 13:17, Pierre-Yves Chibon wrote:
On Thu, Apr 20, 2017 at 12:17:10PM +0200, Stef Walter wrote:
> Okay, that does explain some things. But I do have some follow up questions:
>
> 1. Will Bodhi be modified so that failed tests can gate a bodhi update?
I guess it's doable, I do not know if bodhi's upstream is aware of this request.
I pointed him to this thread so he might chime in.
Good to know. Is this only code changes, and then deploying the changed
version of Bodhi? Or does this (also) involve decision that needs to go
through a Fedora policy committee of some sort?
> 2. Will Bodhi be modified so that tests in progress can prevent
a bodhi
> update?
Same as above
> 3. Will Bodhi be modified so that packages do not get into
> updates-testing by merely creating a Bodhi update? As they do today?
Package won't go into updates-testing by themselves, packagers request it and
rel-eng does it.
Okay, so today it's one step to the packager, but internally it's two
steps. And the latter step (the push) is the thing that would be gated
on CI.
So follow on questions here:
a) How does a packager request CI be run again for an update, eg: if CI
failed due to flakiness. If we're gating updates the point of gating
(bodhi) is very far from the point of change (dist-git push) and
therefore this becomes more important than ever.
b) Should tooling be created to request a dist-git build and Bodhi
update in a single step?
So for all thre points above, maybe the right place to do this would
be the
rel-eng tooling to prevent builds failing their tests to be pushed.
Where is this tooling? Is it proprietary (yes Fedora-only hidden scripts
are proprietary) or open source?
> 4. Will the CI pipeline and the Fedora Atomic host that it
produces
> be composed of some packages that are not yet in 'updates-testing'?
If I understood correctly Ari's pipeline, that is the case yes since (again,
iiuc) the package is built and the compose done from a dist-git commit, so
testing a different build from what is going to bodhi and then updates-testing.
> 5. How will the next run of the CI pipeline select the known good set
> of packages? Will it use updates-testing?
I'll defer this to the CI pipeline folks :)
> 6. Lastly, how does or might this work with rawhide?
If rawhide gets gated in bodhi (which is something I'm in favor of but needs to
go through other loops), then yes. Otherwise no since there would be no gating
point.
Rawhide becomes important once we get past the next branch point (eg:
Fedora 27). The master branch of dist-git will have no tests unless
there is testing in place there, but more likely any tests that have not
been run on rawhide will all of a sudden start to fail at the branch point.
In other words, not a blocker for a proof of concept, but for this CI
effort to outlast the PoC stage, rawhide is absolutely a requirement.
Cheers,
Stef