6:40 a.m.
Finally a few coding comments from me:
lib/python/util.py:
-def get_basearch():
+def get_basearch(arch = None):
'''like get_arch, but returns the basearch (as used by yum
etc.)'''
- arch = os.uname()[4]
+ if arch == None:
+ arch = os.uname()[4]
if arch in ('i486', 'i586', 'i686'):
arch = 'i386'
elif arch == 'ppc64':
Please adjust the docstring, thanks.
hooks/post-koji-build-batch/README:
The watcher is actually in the post-koji-build directory, because querying Koji
takes quite a lot of time, and we do not need to do it twice.
It runs quite fast right now (jskladan made some optimizations), the
code sharing is the main reason for now I believe.
hooks/post-koji-build/watch-koji-builds.py:
watch-koji-builds.py:
if tag.endswith('-pending'):
harnesscall += ['post-bodhi-update-batch']
We don't have hooks/post-bodhi-update-batch/ directory, this shouldn't work?
There's also a lot of commented out code, maybe it's ready for deletion?
Sample output of the script:
Scheduling koji events for dist-f14-updates-candidate
autoqa autoqa post-koji-build --kojitag dist-f14-updates-candidate --arch x86_64 --arch
i386 wireshark-1.4.3-1.fc14
There seems to be 'autoqa' word listed twice.
And some generic comments:
jskladan wrote:
We assume, that if the package has -pending tag, it was already tested
in the -updates-candidate stage, so I'm removing it from the -updates-candidate
listing, so the tests do not run twice needlessly.
Do we have this situation covered?
1. koji watcher runs at 13:00.
2. build foo-1.1 is tagged with -updates-candidate at 13:01.
3. build foo-1.1 is tagged with -updates-pending at 13:03.
4. koji watcher runs at 13:05.
In this situation we can't remove foo-1.1 from -updates-candidate
list, can we?
jskladan wrote:
At the moment, the post-bodhi watcher is still active, so I did not
feel the need to implement this functionality right now, but it's
true, that this might be confusing.
But the post-bodhi-update watcher script should be deleted shortly,
right? IIUC the bodhi watcher script shouldn't be needed anymore,
everything will be managed by the koji watcher.
jlaska wrote:
The important thing is that as long as we can clearly articulate that we
monitor for different events: post-koji-build, post-bodhi-update and
post-bodhi-batch-updated, it doesn't matter if it's all a single watcher
script triggering the events. I wouldn't want to advertise to test
authors that in order to monitor for bodhi-updates, you trigger on
'post-koji-build' with tag.endswith('-pending'). That exposes too much
implementation detail that the test author shouldn't need to know.
Definitely. I agree it's better to keep the different hook names
and let tests distinguish the events according to that hook name.
On the other hand, I'm not really opposed to having a single script
triggering those events (post-koji-watcher). The code is so similar
that yes, we could do a shared library and have two (or four)
distinct watchers, but it looks like a waste of energy.
The problem is that we've hit limits in our architecture (which
happens often, every time a new use case appears). As usual, we
need to change some basics a bit and refactor the relevant code.
Currently, things like collapsing architectures (running tests
for several archs at once) or batching events makes the whole our
process look quirky. We have to re-think some stuff a bit.
Some basic changes are already shaping in my mind. For example,
(as josef correctly noted), the important information for a test
is the event type - not the watcher script name! Until now, the
event type matched the hook name 1:1. That's no longer the case.
I believe we will soon remove the hook name from autoqa command
line and use event name instead. Then it won't really matter if
one hook triggers two different events or two different hooks
trigger the same event.
We will have to remake events batching into a single common layer
between the hooks and the tests. We can't implement this in the
individual hooks forever (it won't be possible with Fedora Message
Bus).
Etc, etc.
Those are larger changes, however, so I think currently the proposed
approach is sufficient. It also better aligns with my future ideas.