Koji 1.22.0 is out. Thanks to everyone who contributed!
You can read release notes here:
https://docs.pagure.org/koji/release_notes/release_notes_1.22/
Highlights:
* dropped krbV support (and replaced by gssapi)
* dropped py2 support for hub and web
* volume policy has more info for non-rpm content
* windows builds works again with new libvirt
* mergerepo_c is now used whenever possible
* mock bootstrap support
* new repoinfo page in web ui
* various kojira improvements
* speed improvements
* lots of docs
* with 1.21.1 it makes 129 PRs merged!
You can view the 1.22 roadmap at https://pagure.io/koji/roadmap/1.22
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
Hi folks,
I was working with another developer recently to run Koji's unit
tests. There are a couple of different ways to do it.
1. The Makefile provides a few targets, like "make test", which runs
"make test2" and "make test3"
2. https://jenkins-fedora-infra.apps.ci.centos.org/job/koji sets up a
virtualenv (with --system-site-packages) and runs the tests through
that.
I think there is an opportunity to unify and modernize this. Ideally
we'd have one way to run the tests, and we could simplify the Jenkins
job configuration so that it's easier to replicate the exact Jenkins
job commands locally.
We're looking into running the unit tests with tox, a tool that fits
well with Python's virtualenv and allows us to execute tests with
multiple Python versions. Tox is used across several other projects
like Pungi and rpkg.
We're working on a prototype that works on CentOS and Fedora. We
should have a pull request up soon.
- Ken
Someone was asking me recently why hub/kojihub.py has a convention like:
listChannels = staticmethod(list_channels)
Is it fine to just remove this and use the @staticmethod decorator on
all the "public API" methods everywhere?
- Ken