Koji 1.28.0 release
by Tomas Kopecek
Koji 1.28.0 is out. As usual Thanks to everyone who contributed!
You can read release notes here:
https://docs.pagure.org/koji/release_notes/release_notes_1.28/
Highlights:
* 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
1 year, 9 months
Koji operator demo
by Leonardo Rossetti
Hello all,
I would like to share a video[1] where I show how to deploy Koji in
Kubernetes through the operator[2] (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
components.
This is part of an effort in making it available in Kubernetes through the
operator-hub[3] and possibly with other applications/tools used by
Fedora/CentOS as well.
Warning: the video is 21 minutes log :-)
Any feedback is always welcome :-)
[1] - https://youtu.be/rXZaO8LxqWw
[2] - https://pagure.io/kube-sig/koji-operator
[3] - https://operatorhub.io/
Regards,
--
Leonardo Rossetti
Senior Software Engineer,
Red Hat <https://www.redhat.com>
lrossett(a)redhat.com
<https://www.redhat.com>
1 year, 9 months
Question about `checkHost`
by Ben Alkov
Hi, I have a question about `checkHost`...
AFAIU:
- 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
again*?
Some context:
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[1].
We're looking at "abusing" `checkHost` by defining an override in OSBS'
koji-containerbuild[2] builder to check existing 'OPEN' tasks before taking up a
new one.
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.
[1] 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
':latest' tag
[2] https://github.com/containerbuildsystem/koji-containerbuild
1 year, 9 months
