Automated sanity check that can send an e-mail if there are problems

RESOLVED FIXED in Bugzilla 3.2

Status

()

Bugzilla
Administration
P2
enhancement
RESOLVED FIXED
17 years ago
9 years ago

People

(Reporter: CodeMachine, Assigned: Frédéric Buclin)

Tracking

2.13
Bugzilla 3.2
Dependency tree / graph
Bug Flags:
approval +
documentation +
documentation3.0 +
documentation2.22 +
documentation2.20 +

Details

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

17 years ago
At the moment I believe it's too easy to miss problems with the database.

It would be nice if sanitycheck.cgi could automatically run periodically, and
email the results to a person.

I guess the period would be configurable.
(Reporter)

Updated

17 years ago

Comment 1

17 years ago
This could be done by running cron on the server to run sanitycheck.cgi to 
run and then hack email the results to an address. This is a mozilla.org 
issue, not a bugzilla issue. Maybe this should get kicked over to whoever 
is running the mozilla installation.
(Reporter)

Comment 2

17 years ago
Who has bothered to do this so far?  Anyone?

I think that demonstrates why this would be good "out of the box".  People just
won't bother.  I'm not saying you wouldn't implement it as you say, but it needs
to be a no-brainer to set up as such, like in editparams.cgi or something.

Comment 3

17 years ago
automatically setting cronjobs on host machines would be rather rude. why not 
just add it to the right spot in the documentation?

"we're accepting patches"
(Reporter)

Comment 4

17 years ago
I'm not really sure that running cronjobs is rude, I see lots of packages
running cronjobs on my machine.

But it is of course nice to have as an option.  That's why I suggested
editparams.cgi.

If you do think the documentation's still the best way to go, and I'm not
necessarily disagreeing, this should be a fairly straightforward command or
people will just not bother.
A neat trick I saw used in Majordomo 2.0 is that the documentation has you 
insert two cron jobs that simply call a trigger script with a parameter to tell 
it which trigger it is.  That script will then look at your preferences, and see 
what it's supposed to be doing (if anything) at that point in time.
(Reporter)

Updated

17 years ago
Whiteboard: 3.2
moving to real milestones...
Whiteboard: 3.2
Target Milestone: --- → Bugzilla 3.2
Severity: trivial → enhancement
(Reporter)

Comment 7

16 years ago
Moving to new Bugzilla product ...
Assignee: tara → justdave
Component: Bugzilla → Administration
Product: Webtools → Bugzilla
Version: other → 2.13

Comment 8

15 years ago
This should start as a sanitycheck that can be run from a command line with a
switch to either generate output on error only or regardless and have a return
code appropriate to the result.

Then, this could eventually find its way into a test suite as well.
(Reporter)

Comment 9

14 years ago
Joel, what do you mean "a test suite" - isn't it already a test suite?
Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.
Assignee: justdave → administration
QA Contact: mattyt-bugzilla → default-qa
(Assignee)

Comment 11

12 years ago
(In reply to comment #8)
> This should start as a sanitycheck that can be run from a command line with a
> switch to either generate output on error only or regardless and have a return
> code appropriate to the result.
> 
> Then, this could eventually find its way into a test suite as well.
> 

Taking! I didn't have in mind to convert it to t/010sanitycheck.t, but that could be a good idea... except tinderboxes will crash as they have no DB. ./runtests.pl is not supposed to do calls to the DB.

What I had in mind is to have sanitycheck.pl which would be run from the command line or from a cron job, which basically would do nothing more than calling Bugzilla->batch(1) and then get the output from sanitycheck.cgi and send it per email if problems are found. As I'm going to templatize sanitycheck.cgi in bug 312197, I will try to make this possible at the same time.
Assignee: administration → LpSolit
Depends on: 312197
Priority: P3 → --
Target Milestone: Bugzilla 3.2 → Bugzilla 2.24

Comment 12

12 years ago
If you are calling sanitycheck from a crontab, you probably also want to make it selectable to either send the results regardless or to send only errors.  A command-line switch for that would be fine.
(Assignee)

Updated

11 years ago
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2

Updated

11 years ago
Priority: -- → P2
Summary: Automated sanity check and e-mail. → Automated sanity check that can send an e-mail if there are problems
(Assignee)

Comment 13

11 years ago
Created attachment 258054 [details] [diff] [review]
patch, v1
Attachment #258054 - Flags: review?(mkanat)

Comment 14

11 years ago
Comment on attachment 258054 [details] [diff] [review]
patch, v1

>+my $verbose = 0; # Return all comments if true, else errors only.
>+my $login = '';  # Login name of the user which is used to call sanitycheck.cgi.
>+
>+my $result = GetOptions('verbose' => \$verbose, 'login=s' => \$login);
>+
>+Bugzilla->usage_mode(USAGE_MODE_EMAIL);

  This should actually be USAGE_MODE_CMDLINE. USAGE_MODE_EMAIL is when Bugzilla is being used through the inbound email interface.

>+my $user = new Bugzilla::User({ name => $login })
>+  || ThrowUserError('invalid_username', { name => $login });

  I know this seems strange, but apparently there could be a user in the database with an empty login_name (if somebody manually edited the DB). So we should check to make sure $login isn't empty, also.

>Index: template/en/default/email/sanitycheck.txt.tmpl
>+  # The Initial Developer of the Original Code is Frédéric Buclin

  There needs to be a copyright also, there.

>+[% output %]

  You should FILTER txt here, or you get output like this:

flags.requestee_id
    (<a href="show_bug.cgi?id=4154" title="NEW - This is just another bug">bug 4154</a>)

  Everything else looks great!
Attachment #258054 - Flags: review?(mkanat) → review-
(Assignee)

Comment 15

11 years ago
Created attachment 258077 [details] [diff] [review]
patch, v2

Keeping USAGE_MODE_EMAIL as per our discussion on IRC (else Bugzilla->login() doesn't let me go further) and setting the Original Developer to Netscape Corp. till someone knows for sure what it should be.
Attachment #258054 - Attachment is obsolete: true
Attachment #258077 - Flags: review?(mkanat)

Updated

11 years ago
Depends on: 373639

Comment 16

11 years ago
Comment on attachment 258077 [details] [diff] [review]
patch, v2

>+# The Initial Developer of the Original Code is Netscape Communications
>+# Corporation. Portions created by Netscape are
>+# Copyright (C) 1998 Netscape Communications Corporation. All
>+# Rights Reserved.

  No, no, this is incorrect. The discussion that I was having with justdave was about something else entirely.

  The correct attribution for new files is their *creator*. The reason that old files say "Netscape" is that Netscape was their creator.

>+Bugzilla->usage_mode(USAGE_MODE_EMAIL);

  I've filed this bug's new blocker so that we can really use USAGE_MODE_CMDLINE now. Just fix that and the above block, and this is r+.
Attachment #258077 - Flags: review?(mkanat) → review+

Updated

11 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 17

11 years ago
Created attachment 258821 [details] [diff] [review]
patch, v2.1

carrying forward mkanat's r+.
Attachment #258077 - Attachment is obsolete: true
Attachment #258821 - Flags: review+
(Assignee)

Updated

11 years ago
Flags: approval+
(Assignee)

Comment 18

11 years ago
Checking in sanitycheck.cgi;
/cvsroot/mozilla/webtools/bugzilla/sanitycheck.cgi,v  <--  sanitycheck.cgi
new revision: 1.129; previous revision: 1.128
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/sanitycheck.pl,v
done
Checking in sanitycheck.pl;
/cvsroot/mozilla/webtools/bugzilla/sanitycheck.pl,v  <--  sanitycheck.pl
initial revision: 1.1
done
Checking in Bugzilla/Install/Filesystem.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Filesystem.pm,v  <--  Filesystem.pm
new revision: 1.19; previous revision: 1.18
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/template/en/default/email/sanitycheck.txt.tmpl,v
done
Checking in template/en/default/email/sanitycheck.txt.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/email/sanitycheck.txt.tmpl,v  <--  sanitycheck.txt.tmpl
initial revision: 1.1
done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Keywords: relnote
(Assignee)

Updated

10 years ago
Blocks: 182083
Flags: documentation?

Comment 19

10 years ago
Created attachment 298010 [details] [diff] [review]
docs patch for sanitycheck email

this bug is just about adding the email/automation functionality, but in looking for where to document i realized there is no documentation about sanity check except in the FAQ (please correct me if I'm wrong). I put this in the administration section. First draft here - let me know what you think.
Attachment #298010 - Flags: review?(documentation)
(Assignee)

Comment 20

10 years ago
Comment on attachment 298010 [details] [diff] [review]
docs patch for sanitycheck email

>+    To run the "Sanity Check" script, log in as an Administrator and click the
>+    "Sanity Check" link in the footer.

FYI, admin links are no longer displayed in the footer in Bugzilla 3.2. There is a single link pointing to admin.cgi, a page which lists all possible actions. This can be fixed on checkin, so r=LpSolit
Attachment #298010 - Flags: review?(documentation) → review+
(Assignee)

Comment 21

10 years ago
tip:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.79; previous revision: 1.78
done


I also backported this patch to 3.0, keeping only the part about sanitycheck.cgi.

3.0.3:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.70.2.6; previous revision: 1.70.2.5
done
Flags: documentation?
Flags: documentation3.0+
Flags: documentation+
(Assignee)

Comment 22

10 years ago
While I'm on it, I used the same backport on 2.20 and 2.22 branches:

2.22.3:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.55.2.13; previous revision: 1.55.2.12
done

2.20.5:

Checking in docs/xml/administration.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/administration.xml,v  <--  administration.xml
new revision: 1.50.2.16; previous revision: 1.50.2.15
done
Flags: documentation2.22+
Flags: documentation2.20+

Comment 23

9 years ago
Added to the Bugzilla 3.2 release notes in bug 432331.
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.