On Thu, Apr 20, 2017 at 01:34:22PM +0200, Stef Walter wrote:
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.
Currently it is done automatically, creating the update triggers the taskotron
run.
For CI, afaiu, Ari wants to trigger on commits and if we wanted to move this to
bodhi update, then I think we would re-use the same trigger message as taskotron
and a list of packages of interest.
b) Should tooling be created to request a dist-git build and Bodhi
update in a single step?
This was a little bit the idea behind: fedobuild:
https://pagure.io/fedobuild
(demoed at DevConf 2017).
With some additional meta-data provided on commit, it would trigger a koji build
and if successful automatically creates the corresponding bodhi update.
> 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?
Entirely open-source just like everything else in Fedora.
Dennis or Randy may know better than I, but I believe this is part of the famous
`mash` script that creates the repo.
>> 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
No tests as in "will not have test" or as in " will not be tested/have its
tests
run"?
Because the former would be false while the later would be as true as before
branching.
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.
I'm not sure I entirely follow you here :)
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.
That means introducing a gating point for rawhide and I can only think of Bodhi
among the existing applications to be it.
Pierre