question for all: how are you using koji-usage (if you even know about
This is a bunch of random script with various level of maturity living in
pagure . They are nor packaged, nor distributed anywhere. I've gone
through old PRs there and seen one from Pavol Babincak proposing setup.py.
Maybe it makes sense for someone to have it installed in virtualenv, maybe
it also makes sense to provide some basic spec file (that was my PR
proposing splitting these tools to cli plugins and rest). Not sure about ad
hoc PyPi distribution.
We don't plan to give it much better shape, but for some more mature
scripts it would make sense to promote them to basic koji (blinking in
koji-ssl-admin direction). I'll add some paragraph about this possibility
to README.md there.
Tomas Kopecek <tkopecek(a)redhat.com>
Release Engineering Development, RedHat
I've been working on a project that is investigating using Spack (https://spack.io/) to deploy a common development environment across HPC centers. Like many other ports collections, Spack began as a build system but has developed its own packaging format, referred to as build caches. I've made a prototype pass at using koji plugins to generate these build caches, which has worked well enough to demonstrate that we can share the infrastructure and build functional caches, but has of course spawned some questions.
1) Looking at the Content Generator docs, the model workflow only use Koji as a convenient repository for artifacts and metadata built entirely outside of Koji. Is this API still the right one to use if the builds are being done via a builder plug-in? Should I then call CGImport() from the build task and use a post-import hub callback for hub-side finalization, or does it make more sense to add a completion call on the hub, much like it's done for existing builds?
2) Content Generators seem to still require an RPM-style NVR uniqifier. Spack relies only on package names and a cryptographic hash of the sources, dependencies, and build options -- somewhat akin to Nix. My plan is to use the hash as the package version, and the release as a serial number, in case the same package hash needs to be rebuilt. This seems like it should work, but I'm a bit worried that it's non-standard. How closely are Content Generators expected to follow RPM NVR conventions, such as small string lengths, and monotonically-increasing versions?
3) There are a number of classes/functions that currently live in kojid or kojihub.py, which seem like they're broadly useful to plugins. In particular, I would like to lean on the BuildRoot and BaseBuildTask classes from kojid, and the Host and Task classes and get_tag(), get_user(), get_build_target(), and make_task() functions from kojihub.py. Would it make sense to move these into the koji library?
4) Has any thought been given to how the web interface could be made more extensible? While it mostly works with plugin-provided task types, things aren't perfect. For instance, they do not show up in the "Method" filter, and there is no "Watch task" support.
*Meeting docs: *https://pad.mozilla.org/p/KojiFeb2020
*Meeting Time:* Feb 12 2020 10:00-11:00AM US/ET
*Where: * https://bluejeans.com/1265288041
- Dennis Gregorovic, Jana Cupova, Tomas Kopecek, Brendan Reilly, Neal
Gompa, Chris O'Brien, Ken Dreyer, Lisa Smith, Jiri Kriz, Mike McLean, Yuli
Wang, Michal Faruga, Yuming Zhu, Nicholas Burr, Andrew Hills, Jonas Brauer,
Pierre-Yves Chibon (pingou), Kevin Fenzi
8 upstream koji users besides koji/brew development team joined this
meeting. We shared latest Koji release and collected some feedback.
then shared next koji release planning, talked if move sidetag plugin
to koji etc. more detail please check following notes.
*Meeting notes: *
- Koji 1.20 released
- Feedback or retrospective
- bulk uploads have been a huge performance improvement
- smooth release / upgrade
- Kudos to team on getting so many fixes in
- additional dist-repo / zchunk configuration per tag is requested (for
- Koji1.20.1 - bugfix
- Proposed issues so far -
- Proposed issues so far -
- 54 issues planned now, plan release on Apr.
- MBS plans progress?
- Red Hat's koji team (brew team) is going to take on development of MBS.
- Others you want to talk:
- sidetag plugin - do we want it moved into koji itself?
- Neal: yes! magaei would really like this. lots of potential with the
- Mike: keeping it as a plugin sets the right expectation that this is
_a_ solution but not necessarily _the_solution
Last Meeting(Nov 20, 2019) action items review:
- Follow up with Brew QE and Ken to see how we can collaborate on Koji
- Jana: Brew QE did connect with Ken and has plans for using playbooks
in the future
- add koji-devel to calendar invite for future community meetings
- Yuli update: koji-devel@ was added in the calendar, got replying:
"Your message to koji-devel(a)lists.fedorahosted.org awaits moderator
- Yuli sent out email this Monday for the meeting heads up
- tkopecek: We can set it as a title in #koji IRC channel +- week before
- [kdreyer] that's a good idea
- Still needed
- Make sure that koji.build works
- moving the hosting and domain registration to Red Hat is in progress
and should happen soon
- once that is done, can figure out how to best use koji.huild