On 8/17/19 4:32 PM, Colin Walters wrote:
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/infrastructure@lists.fedora...