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

Re: automated storage test framework



On Mon, 2010-05-10 at 17:14 -0400, Chris Lumens wrote: 
> > > Currently, this code doesn't live anywhere besides a directory on my
> > > computer.  It's not in a local anaconda git branch.  It's not in autoqa.
> > > Is there a good place for this stuff to live, or is it destined to be
> > > off on its own?
> > 
> > Committing this to AutoQA seems appropriate to me.  I can see this
> > living alongside other installation related tests in AutoQA.  Not sure
> > if you have commit privs, but we can certainly fix that.  
> 
> I haven't tried before.  Probably?  Maybe?
> 
> If I put it into autoqa, what do I do with all the reporting stuff?
> Does that then need to get changed to work the way everything else does?
> 
> > What frequency do you anticipate having these tests run?  Every new
> > anaconda build?
> 
> For now, I just see it happening on an as-needed basis.
> 
> Eventually, I think I'd like two things to happen:
> 
> (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 :)  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.  

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.

[1]
http://git.fedorahosted.org/git/?p=autoqa.git;a=tree;f=tests/initscripts;hb=HEAD
[2] http://git.fedorahosted.org/git/?p=autoqa.git;a=tree;f=hooks;hb=HEAD

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

Thanks,
James 

Attachment: signature.asc
Description: This is a digitally signed message part


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