> > (1) Get hardware so we can kick off an automatic run when every anaconda > > build is completed. Do we have that kind of notification framework > > right now? > > We have hardware to support this type of test in QA, but certainly would > appreciate more :) Ah, tracking down hardware is always the big challenge, isn't it? That's why I have things like checkbot running on cutlet. It's easier to rig something up locally than to do it through the official channels. However, I don't want to bog down cutlet with running this. > We have a rough mechanism for initiating > package-specific tests. We do this with the the initscript [1] tests > using the post-koji-build watcher. It could probably be improved, but > this would be a good use case to try it with. Yep, this looks like it could be pretty useful. > Depending on the frequency you want to kick off tests, we could extend > our current AutoQA watchers [2] to also schedule tests when a git commit > is made. Running on every commit is probably overkill, and is certainly an effective way to DoS a machine. Nightly is probably the absolute most frequent I would want to run these tests. If we need more immediate results, I'd save that for requested runs by developers. > > (2) Add support for doing a scratch build from anaconda git, creating a > > repo with that build, and running against that. Then individual > > developers can test out storage changes they're working on that they > > don't have a lot of confidence in. > > Good idea. This is on my short list of things to do, once I finish the test matrix and figure out how to handle errors from doAutoPartition that do not result in tracebacks. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
