#204: Adjust watchers to pass over all information at once (required for depcheck) --------------------+------------------------------------------------------- Reporter: wwoods | Owner: jskladan Type: task | Status: assigned Priority: major | Milestone: 0.4.4 Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by jlaska):
I spoke to wwoods about some of the remaining depcheck tasks, and he discussed a depcheck task dependency on this ticket. He clarified some of my confusion on this ticket ... I'll try to summarize below.
As Kamil notes in comment#2, post-bodhi-update currently will launch 'autoqa' for every new update discovered. Wwoods indicated that this is the desired outcome for the watcher. I didn't understand why until he mentioned that we want our watchers to match the behavior expected in the 'glorious future'. That is, when the message bus is in action, AutoQA would theoretically receive notification about *each* bodhi update. It wouldn't receive a single notification for when the pool of bodhi updates changes (that could certainly be another event to monitor, but it sounds like it was different from the original intent for post-bodhi-update). Additionally, there may be tests that we want to run against a single bodhi-update (rpmlint/rpmguard/initscripts by the looks of http://fedoraproject.org/wiki/QA:Package_Update_Acceptance_Test_Plan)? Will felt we should keep the post-bodhi-update watcher behavior as it is now, but provide some shared code that can grab a list of bodhi-updates needed for testing. This code would be used in the wrapper for tests that need to operate over the entire set, such as depcheck, future-conflicts- test and upgradepath.
Of course, all that is a bit of guess work since we don't have a message bus in action. But it at least describes the original idea for the bodhi event notification. In general though, for tests, like depcheck, that operate over the entire update set ... it's an odd workflow that we haven't yet fully documented. For example, some questions remain for me ... 1. Should the test provide feedback for all packages in the set that PASS, or only the package it was asked to test? This seems like we would have a lot of duplicate testing going on if we only provide feedback for the requested update. 2. If providing feedback against all -pending updates, shouldn't the wrapper get a list of *untested* -pending updates, and only test that set? If no untested -pending updates ... no testing needed? Otherwise, again we'd have repeated testing. 3. Then there is the whole timing issue kparal and wwoods were discussing regarding multiple depcheck tests running at the same time, each trying to move items out of the -pending set, and into the ACCEPTED -pending set.
Will expects to have another blog post published shortly to attempt to answer some questions about the flow. Does this make sense? Are there additional flows we need to consider?