Koji 1.28.0 is out. As usual Thanks to everyone who contributed!
You can read release notes here:
* Security - administrators are now able to enforce rules on various
names (tag, users, etc.) (#2117)
* Permission descriptions - each permission now has also description in
the db. Mainly useful for non-standard permissions which are not covered in
the basic documentation. (#335)
* Tokens in SCM authentication are now accepted (#3179)
* Kiwi support improvements (could become a production-ready in the next
release or two) (#3184, #3202, #3210, #3221)
* documentation updates
* 60 pull requests
You can view the 1.28 roadmap at https://pagure.io/koji/roadmap/1.28
For the current roadmap, see https://pagure.io/koji/roadmap
You can download this and other releases at https://pagure.io/koji/releases
Tomas Kopecek <tkopecek(a)redhat.com>
RHEL Build Development, RedHat
I would like to share a video where I show how to deploy Koji in
Kubernetes through the operator (in its current state) that I am
currently working on.
I also try to explain some of the internal mechanics of the operator in the
video, such as how it uses custom resources to deploy and run Koji
This is part of an effort in making it available in Kubernetes through the
operator-hub and possibly with other applications/tools used by
Fedora/CentOS as well.
Warning: the video is 21 minutes log :-)
Any feedback is always welcome :-)
 - https://youtu.be/rXZaO8LxqWw
 - https://pagure.io/kube-sig/koji-operator
 - https://operatorhub.io/
Senior Software Engineer,
Red Hat <https://www.redhat.com>
Hi, I have a question about `checkHost`...
- kojid's `main` continually loops over daemon.py::TaskManager::getNextTask()
- getNextTask() calls daemon.py::TaskManager::takeTask() (when appropriate)
- and takeTask() calls back into kojid's build-task-class-specific (i.e. some children of BaseBuildTask) `checkHost()`
The question: Is it the case that a failed `checkHost()` call will simply cause a builder to
skip that task and go on to the next, *eventually coming back to check that task
OSBS is being redesigned (reimplemented as well, at this point), and the feature
that we had in the old OSBS which would "pipeline" multiple tasks created from
the exact same repo/branch will no longer work.
We're looking at "abusing" `checkHost` by defining an override in OSBS'
koji-containerbuild builder to check existing 'OPEN' tasks before taking up a
Our primary concern is making sure that a task which is being skipped by
the builders (because it failed the `checkHost` check) will still be picked up
once `checkHost` clears.
 Primarily to avoid the situation where build 1 starts, then build 2, both
from exactly the same repo/branch, but for reasons build *2* finishes first
(happens all the time...), and build *1* gets tagged ':latest' in the registry -
this is surprising to end-users who expect the last *requested* build to get the