new txkoji side project
by Ken Dreyer
Hi folks,
Recently I wrote a Twisted-based chat bot that can interact with a Koji hub.
To do this, I wrote a "txkoji" client library:
https://github.com/ktdreyer/txkoji
(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.
- Ken
5 years, 11 months
Koji 1.15.0 release planned for Monday 12/18
by Michael McLean
*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:
https://pagure.io/koji/issue/745
If you are aware of an blockers for the release, please raise them here or
on PR#745.
Please test the current code if you can. Santa is watching :)
5 years, 11 months
Content generators importing scratch builds?
by John Casey
Hi,
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
future?
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?
Thanks,
-john
5 years, 12 months
The 1st Koji Community Meeting Notes - Dec 6, 2017
by Yuli Wang
*Meeting Purpose:* Improve Brew/Koji communication with
upstream(community)
*Attendees:* ngompa(Neal Gompa ), dgilmore, .dgregor , breilly,
tkopecek, yzhu, eberdnik, puiterwijk ,Don Zickus, Jeff Burke , Pat
Riehecky, William Peck, Mike McLean, Jon Disnard, Yuli
*Summary:*
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.
*Meeting Notes/Actions:*
- 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
the productization
- Neal - fedora rust sig / using koji in mageia -
https://wiki.mageia.org/en/Feature:Migrate_to_Koji
- 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
deprecated
- 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
bus?
- 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
https://pagure.io/koji/stats#authors
- 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
- https://pagure.io/sigul/blob/master/f/tests/kojikrb5.at
-
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji...
- puppet module in SL, I can post it somewhere..
- wiki for koji ? NO，but docs
https://docs.pagure.org/koji/server_howto/
- *#koji *could use more activity
- "office hours" would be particularly useful
*Recordings: *https://bluejeans.com/s/bbuPK
More detail please check
https://public.etherpad-mozilla.org/p/KojiDecember2017
Thanks,
Yuli
6 years
New to building for ARM; need some config help
by John Florian
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:
Linux koji-b3-f27.doubledog.org
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.
6 years
Koji Community Meeting on Dec, 6 Reminder
by Yuli Wang
Hello, All
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*
Thanks,
Yuli
6 years
How do enable Python 3 support?
by John Florian
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?
6 years
