I don't understand the tagger/pool/testing-devel/bodhi interactions

[Colin Walters]

II wanted to try out the fix
https://github.com/coreos/ignition-dracut/pull/93

So I pushed the usual "manual integration" bump
https://src.fedoraproject.org/rpms/ignition/c/f83f249db4a391df96c6a178648...
(Which also required
https://src.fedoraproject.org/rpms/ignition/c/a08755a3b9feb7d75b567fcdc76...
but that's irrelevant here)

What I don't understand now is how (or if!) the "tagging" stuff at
https://github.com/coreos/fedora-coreos-releng-automation/blob/master/cor...
is supposed to do anything now.

$ koji latest-pkg coreos-pool ignition
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
ignition-2.0.1-1.gite75cf24.fc30          coreos-pool           ajeddeloh

I think based on reading the code it's parsing the rpm-ostree lockfile but...what
updates that and how?

And is it right to say that to update the traditional f30 tag:

$ koji latest-pkg f30 ignition
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
ignition-0.31.0-6.gitf59a653.fc30         f30                   dustymabe
$ 

It requires the "manual testing commentary" system in Bodhi?

Do we expect to do manual testing stuff in Bodhi or is the idea we ignore it for FCOS
packages with the pool/tagger?

[Dusty Mabe]

On 8/17/19 4:32 PM, Colin Walters wrote:
>  II wanted to try out the fix
>  https://github.com/coreos/ignition-dracut/pull/93
>  
>  So I pushed the usual "manual integration" bump
>
> https://src.fedoraproject.org/rpms/ignition/c/f83f249db4a391df96c6a178648...
>  (Which also required
> https://src.fedoraproject.org/rpms/ignition/c/a08755a3b9feb7d75b567fcdc76...
> but that's irrelevant here)
>  
>  What I don't understand now is how (or if!) the "tagging" stuff at
>
> https://github.com/coreos/fedora-coreos-releng-automation/blob/master/cor...
>  is supposed to do anything now. 

It will, but it's not quite automated yet. I do have the coreos-koji-tagger running in
prod
and it's monitoring the manifest lockfile in the testing-devel branch of the
fedora-coreos-config
repo. The piece that is missing is the updating of the lockfile on the testing-devel
branch. jlebon
is working on that piece using `config-bot`:
https://github.com/coreos/fedora-coreos-releng-automation/tree/master/con...

>  
>  $ koji latest-pkg coreos-pool ignition
>  Build                                     Tag                   Built by
>  ----------------------------------------  --------------------  ----------------
>  ignition-2.0.1-1.gite75cf24.fc30          coreos-pool           ajeddeloh 

For now we are manually tagging into coreos-pool if we need it. I just put this in
the tag so you should be able to pick it up now!

$ koji latest-build coreos-pool ignition | tail -n 1
ignition-2.0.1-2.gite75cf24.fc30          coreos-pool           walters

>  
>  I think based on reading the code it's parsing the rpm-ostree lockfile but...what
> updates that and how? 
IIUC config-bot will be updating the lockfile (I think via a pull request??) and we'll
approve
by merging. 

>  
>  And is it right to say that to update the traditional f30 tag:
>  
>  $ koji latest-pkg f30 ignition
>  Build                                     Tag                   Built by
>  ----------------------------------------  --------------------  ----------------
>  ignition-0.31.0-6.gitf59a653.fc30         f30                   dustymabe
>  $ 
>  
>  It requires the "manual testing commentary" system in Bodhi? 
We'll be able to fast track things into testing-devel via overrides. For things we
need
to be faster than the rest of Fedora we can add in and not be blocked.

>  
>  Do we expect to do manual testing stuff in Bodhi or is the idea we ignore it for FCOS
> packages with the pool/tagger? 
We are still planning to follow the process of the rest of Fedora and submit packages to
bodhi, but bodhi won't play into our 'critical path'. The goal is to have FCOS
not differ 
from the rest of Fedora other than in packages that we've specifically fast tracked,
but
we also want those fast tracked packages to make it to the rest of fedora too (i.e.
minimizing
the delta).

In the future we'd like to have bodhi use our automated testing results as "good
enough" for
sending a package to stable without requiring manual user +1 karma, but since bodhi
isn't on
the critical path for us this will probably be next year. Regarding "having bodhi use
automated
test inputs to send to stable" see [1]

Dusty

[1]
https://lists.fedoraproject.org/archives/list/[e-mail]...