123957 - run checksetup.pl non-interactively (for use with cron jobs on test installs)

Status: RESOLVED FIXED

(Bugzilla :: Administration, task, P1)

Description

[Dave Miller [:justdave]]

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.

Comment 1

[Joel Peshkin]

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
[e-mail],"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.

Comment 2

[Matthew Tuck [:CodeMachine]]

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

Comment 3

[Joel Peshkin]

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.

Comment 4

[Joel Peshkin]

Attachment: Optionally non-interactive checksetup.pl

How's this???

Comment 5

[Bradley Baetz (:bbaetz)]

Comment on attachment 96624 [details] [diff] [review]
Optionally non-interactive checksetup.pl

You should die on errors in the $ARGV[0] script.

Comment 6

[Joel Peshkin]

Attachment: v2

does do or die or die	(what a pain)

Comment 7

[Joel Peshkin]

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 8

[Bradley Baetz (:bbaetz)]

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)

Comment 9

[Joel Peshkin]

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        

Comment 10

[Dave Miller [:justdave]]

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.

Comment 11

[Joel Peshkin]

 
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.

Comment 12

[Dave Miller [:justdave]]

all yours

Comment 13

[Joel Peshkin]

Attachment: Further patch (used in addition to v2) to die if missing a prompt answer

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 14

[Dave Miller [:justdave]]

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 15

[Joel Peshkin]

Attachment: Revised patch supresses routine output

Comment 16

[Dave Miller [:justdave]]

Comment on attachment 97734 [details] [diff] [review]
Revised patch supresses routine output

works like a charm. :-)

Comment 17

[Joel Peshkin]

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