On Tue, 2009-05-19 at 00:09 -0700, Paul Thomas wrote: > On Mon, May 18, 2009 at 10:49 PM, Zach Welch <[email protected]> > wrote: > Hi all, > > Since this weekend, I have spent some time working on a set of > Perl > scripts to prototype the back-end system that will aggregate > the data > and present it for review (pre-analysis). [snip] > Known problems: > - I have tried to KISS, so there are going to be definite > limits. > - Additional database design work needs to be done. > - Static output only. > - Missing an 'email.pl' script to provide a gateway from > e-mail messages > sent by the automated tester. > - Automated tester does not report PASS/FAIL and send e-mails. [snip] > > I think that would be great. As a user what is our interface to this? > Do we just send an email with lines in the specified format? I haven't > used the regression test suite so maybe that would explain this some.
The "test suite" was just started recently (look in src/target/test/). It's a work-in-progress, but the goal will be to "connect the dots" between scripts like this and a my current work. > One way to aggregate the data would be to create a web form that users > could fill out manually, but also have another perl script in the test > suite that could automatically fill out the form. The most elegant way > would be to tie the form directly to the SQL database, but for > something quick & dirty we could just use a google form like this: > (https://spreadsheets.google.com/viewform?formkey=cnpOSWRCcE9DRjl1a3E5NURnUFQ4Rnc6MA..), > and then pull a csv file of the data when we wanted to. Just a thought. I > know some PERL & SQL so I'm willing to help out. My initial plan was simply to allow a script to call sendmail (SMTP), as I can create an account to receive the messages and deliver them into the DB. However, Duane has me re-considering my backup plan to just using curl and a web form. Either way, the contents will be generated from a locally run script (probably perl, but maybe just shell). I imagine the user involvement requiring at most two steps (after setup): 0) Configure your user-preferences. 1) Choose the interface and target to test (platform may be inferred). 2) Run 'make INTERFACE=X TARGET=Y smoketest' (or something similar). - For some platforms, may run it from OpenOCD's built-in web server. For users with only one system configuration to test, Step 1 should only need to be done once. Thus, many users should simply be able to run the last command, after 'make setup_smoketest' perhaps. In theory. The purpose of TAB-delimited files would be to allow trivial importing into an SQL database, which I have considered required from the start (just not for the very first version). Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
