Recently I wrote a Twisted-based chat bot that can interact with a Koji hub.
To do this, I wrote a "txkoji" client library:
(the bot code is separate, this is just the koji client library)
txkoji allows me to interact with a Koji Hub in an event-driven way,
without blocking the reactor for my program. This works well for
client programs that must be responsive to input from several sources
(like IRC and a message bus and many other inputs). I return the
XML-RPC responses as Munch (dict-like) objects because I ran across
Munch in a couple other Fedora infra projects and I like the syntax.
If Koji gets a REST API, I could convert this to use treq instead of
Twisted's XML-RPC client.
*All I want for xmas is a Koji release*
*A Koji release*
*See a Koji releaseGee, if I could only have a Koji releaseThen I could
build -u merry_xmas*
Development froze on Monday. The release PR is here:
If you are aware of an blockers for the release, please raise them here or
Please test the current code if you can. Santa is watching :)
I'm wondering if it's possible to import builds (via content generator) as
scratch builds, so they get cleaned up automatically at some point in the
We're working on a system that will be doing continuous development /
continuous delivery, and spans three different build systems. One is Koji,
but the other two will use Koji's content generator interface for passing
build data between the different systems.
We're trying to create a system where each PR triggers a whole workflow of
builds and test runs. However, in these cases we KNOW these are not
shippable builds, so we want to make them ephemeral in all of the build
systems. Obviously, cleanup tasks become a concern here, since we will
probably be doing many of these builds.
I think we could probably untag builds in Koji from an external system in
order to trigger GC of these temporary builds, but it seems like it would
be simpler to use a native cleanup routine in Koji.
Is this feasible?
*Meeting Purpose:* Improve Brew/Koji communication with
*Attendees:* ngompa(Neal Gompa ), dgilmore, .dgregor , breilly,
tkopecek, yzhu, eberdnik, puiterwijk ,Don Zickus, Jeff Burke , Pat
Riehecky, William Peck, Mike McLean, Jon Disnard, Yuli
We had the 1st Koji community meeting on Dec, 6 with 15 attendees from
upstream, Kernal CI, Engineering team and so on. The lively discussion on
koji last for more than 60 mins and left several action items for Koji.
Stay tuned our next Koji meeting - Feb 7.
- Changes in the last year
- Brew/Koji team expanded development and more frequent releases
- Dedicated QE resources - Effort on test coverage and automation
- Koji 1.15
- roadmap: https://pagure.io/koji/roadmap?status=all&milestone=1.15
- schedule: plan code Freeze on Dec 8, release around Dec 15
- User discussion / input : Fedora rel-eng
- Koji 1.16
- roadmap: https://pagure.io/koji/roadmap?status=all&milestone=1.16
- Community Feedback
- kernel CI - potentially hundreds of kernel builds a day. How do we
scale to that with koji?
- systems engineering team (jeff burke) looking at bringing CI into
- Neal - fedora rust sig / using koji in mageia -
- papat - scientific linux - koji namespaces
- Message bus plugin is heavily used at scientific linux - just
tracking 'TAG/UNTAG' right now, but it is the core workflow
- Message bus plugins
- koji has two used internally at red hat, one is likely to be
- fedora has its own plugin
- how do external users use the plugins? further discussion would
be useful - Filed https://pagure.io/koji/issue/736
- any thoughts on moving kojid to amqp to further leverage message
- python 3
- cli / library support added in 1.13
- what would be next? builder is the preference
- Neal has done some work that can be helpful here around the
yum dependencies - https://pagure.io/pyrpmmd
- Brew/Koji contribution - Jeff Burke
- At present QE/Automation for Brew, have plan in Koji in future
- Installation / deployment of koji continues to be a pain point
- Brew/koji QE - Ansible deployment, openstack for provisioning
- puppet module in SL, I can post it somewhere..
- wiki for koji ? NO，but docs
- *#koji *could use more activity
- "office hours" would be particularly useful
More detail please check
I have a few Raspberry Pi 3 devices and want my Koji setup to build for
them too. I've started by making one of a Koji Builder -- it's probably
not ideal but I'm really new to the ARM hardware. I'm confused on some
terminology though. In the Fedora mirrors I grabbed (per the Fedora
Wiki instructions) a live image from the "armhfp" part of the tree in
the mirrors. Running uname shows:
4.13.15-300.fc27.armv7hl #1 SMP Tue Nov 21 22:24:22 UTC 2017 armv7l
armv7l armv7l GNU/Linux
No mention of "armhfp" there at all. Looking at FPO's own Koji I see
the f27-build tag lists "armv7hl" in the arches field though the hosts
all seem to show "armhfp".
I'm guessing this like "i386" is to "i686". I figure that I should
probably do similar to FPO with `koji add-host --arches armhfp ...` and
`koji add-tag --arches armv7hl ...`. Is that right?
Also, if anyone can suggest better hardware for a light duty ARM
builder I'd appreciate it.
Here is Koji community meeting reminder in case someone didn't get or note
the meeting invitation:
*Meeting docs: *http://piratepad.net/koji
*Meeting Time:* Dec 6, 2017 9:00-10:00AM US/ET
*Where: * https://bluejeans.com/1265288041
*Proposed Agenda: *
- Koji 1.15 and Koji 1.16 roadmap
- Discuss changes in the last year
- Expanded development
- Dedicated QE resources
- Expanded effort on test coverage and automation
Feel free to add more topics you want to talk.
btw, three email address cannot be recogzinized, Please Pay more attention
about the meeting invitation. *pingou(a)fp.o*, *ngompa(a)fp.o*, *ausil(a)fp.o*
This is Yuli for Brew/Koji Project PM.
Here we would like to invite you to join our first Koji community meeting
which is planned next Wed.(Dec 6)
Feel free to let me know or register in this docs if you are interested in
Welcome to Join.
I am deploying a new builder on Fedora 27 and am getting `ImportError:
No module named koji`. In comparing this with my other CentOS 7
builders, I see the difference appears to be that they have python2-
koji while the F27 builder has python3-koji. If I install python2-koji
the builder is able to start successfully.
First this seems like a packaging bug somehow. I'd blame the deps, but
I get the desire to be moving to Python 3 where possible. So I imagine
that there's some config option that tells the builder which to use? I
looked at a virgin kojid.conf but didn't see any hint. Nor did I in
the 1.14 release notes. What am I missing?