[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: automated storage test framework



> > (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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]