adding "NotFound errors to koji
by Ken Dreyer
Let's add more granular exceptions when resources do not exist.
Siege has written some client code that screen-scrapes faultStrings
and puts those into more granular exceptions. Here's the list he's
come up with. From
https://obriencj.preoccupied.net/koji-smoky-dingo/kojismokydingo
NoSuchArchive
NoSuchBuild
NoSuchChannel
NoSuchContentGenerator
NoSuchPackage
NoSuchPermission
NoSuchRPM
NoSuchRepo
NoSuchTag
NoSuchTarget
NoSuchTask
NoSuchUser
Since we assign numeric faultCodes sequentially as we add exceptions
to Koji, it makes sense to me that we'd add these to koji in one go so
they are ordered alphabetically.
The one I'm especially interested in is "NoSuchUser" for
https://github.com/ktdreyer/koji-ansible/issues/221
I'm also wondering how long we have to wait to use these error classes
on the hub, after we've shipped them in the main koji/__init__.py.
1 year, 9 months
Koji 1.27.0 release
by Tomas Kopecek
Koji 1.27.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.27/
Highlights:
* Building images with Kiwi - tech preview (#3094)
* dist-repo --write-signed-rpms option - You can now reconstruct signed
rpms needed for distrepo in one step. (#2806)
* Filtering builds by content generator (#1401)
* Full support for head-signed RPMs (#2973)
* Builder and kojira are now automatically restarted on failure (#3081)
* Fixed windows builder on python3 (#3059)
* documentation updates
* 69 pull requests
You can view the 1.27 roadmap at https://pagure.io/koji/roadmap/1.27
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, 10 months
The proper way to write tests for this pull request?
by Otto Urpelainen
Hello Koji devel,
I am trying get pull request #2979 "Add utility function to watch
builds" ready [1]. Functionally, everything is clear enough now, but I
have a problem with regression tests. I can come up with more than one
way to handle them, but I cannot determine which of my options would be
right choice for this code base. A description of the situation follows
with the options I have thought of. Guidance for choosing which one to
pursue would be welcome.
For background, I am aiming for improving fedpkg so that I would wait
for buildroot overrides it creates. The correct wait behavior is already
implemented in 'koji wait-repo', but apart from running that as a
separate process, is not usable from fedpkg code. My pull request simply
splits the needed wait implementation to a separate, importable
function. The change is quite simple as such.
The test suite already has a tests for the 'koji wait-repo' handler. Now
that a major section of that call is moved to a library function, how
should that new function be tested? The options I have considered are:
1. No new tests are needed. The existing 'koji wait-repo' handler test
already tests the new function, albeit indirectly.
2. New tests are written for the new function. These will naturally have
a large overlap with the existing tests. Let it be so — this is what
happens when a handler for a cli command calls an importable function.
3. New tests are written for the new function, but to avoid duplication,
the old tests are adapted to mock the new function with @patch. This has
the advantages of both testing everything and avoiding duplication, at
the cost of making everything more indirect by introducing more mocks.
This method also does not seem have previous use in the code base. The
mocking examples I find are all about external dependencies: session,
stdout, time and such.
Any thoughts?
Regards,
Otto
[1]: https://pagure.io/koji/pull-request/2979
1 year, 10 months
