We should be able to run checksetup.pl from a cron job without it stalling to ask for input. If this is accomplished by passing it command-line parameters this is fine. Having it not output anything unless there are errors, then output instructions to run it manually to STDERR (which would be mailed to the cron job owner by crond) if input is needed would probably be best.

It seems that it should be possible to permit all of the normal operation to occur, but to accept default values of any LocalVar variables on the command line (overriding the defaults) as well as the vital information about the maintainer. Then, it seems that calling checksetup by running cat /dev/null | ./checksetup.pl -L '$db_host = "localhost"' -L '$db_port = 3306' -L $db_name = "test123"' -L '$db_user = "testuser"' -L '$db_pass = "fooey"' -M justme@here.com,"Me","ee1!we" and check the return code for non-zero results. If Tinderbox were to do this several times... 1) with an empty directory, 2) then reload a snapshot with a data directory and test database (the last major released schema) the bulk of the recent checksetup suprises could be detected automagically.

A solution here might be the front end/back end separation of checksetup.pl, which will allow people to forge their own checksetup scripts.

Proposal for consideration.... If checksetup is passed a filename argument, it should parse the filename and build a hash of predetermined answers to questions that, if specified, supercede requests from STDIN and LocalVar defaults just ahead of reading STDIN or falling back on the LocalVar() declarations. These would have no effect unless checksetup was just about to ask that paritcular question or use that particular localvar.

How's this???

Comment on attachment 96624 [details] [diff] [review] Optionally non-interactive checksetup.pl You should die on errors in the $ARGV[0] script.

does do or die or die (what a pain)

So, eventually, it should be possible for a test that is runnable by developers or tinderbox to do the following... (pseudocode, of course) drop test_database create test_database rm -rf data localconfig checksetup.pl info_about_my_site checksetup.pl info_about_my_site wget -O login.out --save-cookies=filename \ http://xxx.yyy.zzz/query.cgi?GoAheadAndLogIn=1 wget -O sanity.out --load-cookies=filename \ http://xxx.yyy.zzz/sanitycheck.cgi importxml --test < testbugs wget -O test_bug --load-cookies=filename \ http://xxx.yyy.zzz/show_bug?id=1 foreach $test (list_of_test_databases) drop test_database create test_database mysqldump --opt -hlandfill.bugzilla.org -uanonymous -panonymous -P8889 \ $test | mysql -uwhatever -pwhatever $test checksetup.pl info_about_my_site checksetup.pl info_about_my_site wget -O login.out --save-cookies=filename \ http://xxx.yyy.zzz/query.cgi?GoAheadAndLogIn=1&user=testuser1&password=testpassword1 wget -O sanity.out --load-cookies=filename \ http://xxx.yyy.zzz/sanitycheck.cgi Then, according to a series of instructions stored with the test database... wget -O test_bug --load-cookies=filename \ http://xxx.yyy.zzz/show_bug?id=1 wget -O test_query --load-cookies=filename \ http://xxx.yyy.zzz/buglist.cgi.... So, to do this, we would need the following.... some central place would have to have a collection of test databases representing loadable databases made with all legacy supported schemas as well as some odd cases. These could be distributed as SQL stataments in a file from CVS, by http, or by a read-only isolated mysql server. Same issue applies to the xml test bugs. Same issue applies to the series of tests and the key outputs from them. This mechanism could, for example, permit a test to contain a database in 2.14 schema format with a number of users and a number of bugs. After the database is loaded and checked (using an admin user's access), a number of tests could ensure that logins are being granted or denied based on passwords, that non-logged in users can only see certain bugs, that certain users can see certain bugs, etc... Comments?

Comment on attachment 97393 [details] [diff] [review] v2 >@@ -326,7 +351,7 @@ > return if ($main::{$name}); # if localconfig declared it, we're done. > $newstuff .= " " . $name; > open FILE, '>>localconfig'; >- print FILE $definition, "\n\n"; >+ print FILE ($::answer{$name} or $definition), "\n\n"; > close FILE; > } > Everywhere else uses $answer. Apart from that, r=bbaetz x2 (assuming that you've tested)

Checked in with change made. Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.181; previous revision: 1.180 done

This is not solved to my satisfaction. This works great if you know in advance what questions are going to be asked, and for building new installs from scratch from a script for testing purposes. But if a new question shows up that you didn't know about, and hadn't supplied an answer for, checksetup.pl is going to sit there and wait for an answer, which isn't going to be cool in the middle of a cron job. Piping cat /dev/null into it doesn't help, either (makes it worse, in fact) because now checksetup.pl is using up the CPU looping asking you for input over and over because a read past the end-of-file is not a fatal error, only a warning. I tried it and got 145 screens of scrollback full of the undefined value warning followed by checksetup.pl complaining that an email address needs a @ and a . in it before it can be accepted before I could control-C out of it. Here's what I need to run this from a cron job: I don't want to redirect output. I want to get an email any time checksetup.pl makes schema changes or otherwise modifies data or gives warnings to the admin. I don't want to get an email if checksetup.pl didn't have to do anything. This basically means I need a command-line argument that surpresses the version check output and the sendmail reminder, but doesn't surpress anything else. Also, if that command-line argument is present, any prompt for input that doesn't already have a pre-supplied answer needs to cause a die so I know I have to come run it manually to provide that answer the first time.

I debated with myself (I knew I should have gotten someone else into the debate) about what to do if there is no override specified. The simplest approach would be to set a flag when $ARGV[0] is used that causes all the code that would normally prompt to treat the absence of a definition as a fatal.

all yours

This is a patch that works on top of V2 (which is already in CVS) to die if an answer is missing and would have resulted in an interactive prompt.

Comment on attachment 97732 [details] [diff] [review] Further patch (used in addition to v2) to die if missing a prompt answer what about supressing the output from the version checks?

Comment on attachment 97734 [details] [diff] [review] Revised patch supresses routine output works like a charm. :-)

Checking in checksetup.pl; /cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v <-- checksetup.pl new revision: 1.184; previous revision: 1.183 done