mirror of
https://github.com/mozilla/gecko-dev.git
synced 2025-02-01 03:21:10 +00:00
Mega spelling and grammar patch by "Olly Betts" <olly@survex.com> this
is an amazing set of fixes, must have read the whole code found a few inconsistencies in error messages and fixed those too.
This commit is contained in:
kestes%walrus.com
parent
61cd64260c
commit
e69b3c6016
@ -9,12 +9,12 @@ Add support for historical Tinderbox images
|
||||
Mozilla layout preferences are now
|
||||
standard
|
||||
(non uniform row spacing,
|
||||
truely empty cells,
|
||||
truly empty cells,
|
||||
legend on bottom of page).
|
||||
|
||||
Allow users to backdate notices
|
||||
|
||||
autmate regeneration of HTML when user uses CGI
|
||||
automate regeneration of HTML when user uses CGI
|
||||
interface
|
||||
|
||||
Put the C in all build cells.
|
||||
@ -22,7 +22,7 @@ Put the C in all build cells.
|
||||
VC code did the wrong thing when generating old pages and there was
|
||||
no TreeState data.
|
||||
|
||||
Fix Spelling mistakes thoughout code.
|
||||
Fix Spelling mistakes throughout code.
|
||||
|
||||
Add support for build machines to tell the server to add text/links
|
||||
into build cells (TinderboxPrint).
|
||||
@ -70,7 +70,7 @@ this an important feature.
|
||||
Allow Tinderbox to run via suid wrappers. This is needed for some
|
||||
times of mail delivery systems
|
||||
|
||||
No longer exclude 'priveledged id's from running Tinderbox.
|
||||
No longer exclude 'priviledged id's from running Tinderbox.
|
||||
Now we require tinderbox to run as the id which the user specifies
|
||||
is the tinderbox id.
|
||||
|
||||
@ -84,9 +84,9 @@ Begin work to allow tinderbox admin pages to open and close bonsai trees
|
||||
|
||||
fix code which allowed tinderbox to determine the state of bonsai trees
|
||||
|
||||
Major bug in theh untainting code, fixed. This was a security
|
||||
Major bug in the untainting code, fixed. This was a security
|
||||
problem. I suspect people may have trouble with the fix but this was
|
||||
how the code was inteneded to work. I do not understand how this got
|
||||
how the code was intended to work. I do not understand how this got
|
||||
through my unit tests.
|
||||
|
||||
Give a useful example of how use the new build script.
|
||||
@ -120,7 +120,7 @@ Release 0.8
|
||||
This release moved some files into new directories update with
|
||||
cvs update -d -P
|
||||
|
||||
Remove the strict time checking on mail, itcahsed too many problems.
|
||||
Remove the strict time checking on mail, it caused too many problems.
|
||||
|
||||
Fix the Unmonitored Builds in admintree.cgi and in status.html page.
|
||||
|
||||
@ -129,7 +129,7 @@ Storable.pm has been tested as a Persistence implementation.
|
||||
Improve the prediction of when builds will end by introducing the
|
||||
notion of 'deadtime'.
|
||||
|
||||
Separate out the BuildStaus table for easier configuration of the
|
||||
Separate out the BuildStatus table for easier configuration of the
|
||||
status without changing the build display library.
|
||||
|
||||
Better comments in the ReadMe files
|
||||
|
||||
@ -8,7 +8,7 @@ special needs.
|
||||
project and need a GUI to help change various types of project
|
||||
information (treestate, message of the day, etc). They will also need
|
||||
summary pages which will show them the current status of all the
|
||||
projects which they are working on. They may occassionally "drill
|
||||
projects which they are working on. They may occasionally "drill
|
||||
down" into the detailed status page but this will not be their primary
|
||||
view of the tinderbox system.
|
||||
|
||||
@ -18,7 +18,7 @@ build systems (bugzilla, cvs, bonsai, etc). A GUI would not be
|
||||
helpful as local customizations may require small changes to the code.
|
||||
Configurations need to be kept (mostly) in files which are separate
|
||||
from the Tinderbox source code so that they can be version controled
|
||||
and will not get stepped on when tinderbox is upgradded.
|
||||
and will not get stepped on when tinderbox is upgraded.
|
||||
|
||||
3) Developers: need to view the "state of development" and add notices
|
||||
to the notice board.
|
||||
@ -27,7 +27,7 @@ Improvements needed from Tinderbox1
|
||||
-----------------------------------
|
||||
|
||||
highly configurable design with multiple Version Control systems
|
||||
possible (bonsai, raw cvs, perforce, continuious, clearcase) and
|
||||
possible (bonsai, raw cvs, perforce, continuous, clearcase) and
|
||||
multiple modes of running possible (with no version control system
|
||||
with no builds display).
|
||||
|
||||
@ -53,7 +53,7 @@ all programmable configuration parameters should be stored easy change
|
||||
and configure for novice users.
|
||||
|
||||
make better use of the perl data structures to mirror the way we wish
|
||||
to use the data. This will allow easier maintainabilty and allow for
|
||||
to use the data. This will allow easier maintainability and allow for
|
||||
more expansion of features.
|
||||
|
||||
display should work on many different browsers.
|
||||
@ -61,7 +61,7 @@ display should work on many different browsers.
|
||||
popup windows should not be netscape specific.
|
||||
|
||||
Permanent data should be stored via datadumper so that the data and
|
||||
datastrucutres are easy to read and debug. Currently this is a
|
||||
data strucutres are easy to read and debug. Currently this is a
|
||||
performance bottle neck with a large percentage of our cpu time during
|
||||
testing being spent in Data::Dumper::Dump. The perl module Storable
|
||||
is much faster. I wish to not add additional module requirements at
|
||||
@ -76,7 +76,7 @@ this time, this will be configurable.
|
||||
# (out of 19.03 User/102.15 Elapsed Seconds)
|
||||
# was spend in 32878 calls to Data::Dumper::_dump()
|
||||
|
||||
# System Time was negligable at 2.49 Seconds
|
||||
# System Time was negligible at 2.49 Seconds
|
||||
|
||||
All errors should be trapped and sent to log files. Strange program
|
||||
states should be explicitly checked for.
|
||||
@ -86,7 +86,7 @@ to race conditions.
|
||||
|
||||
All column modules (processmail, build, VC, Notices) should be able to
|
||||
be run individually. Modules should accept well defined text files as
|
||||
input and produce text files as output. This will greatly inhance the
|
||||
input and produce text files as output. This will greatly enhance the
|
||||
ability to test each module in isolation and to quickly port modules
|
||||
to new architectures.
|
||||
|
||||
|
||||
@ -25,10 +25,19 @@ To install:
|
||||
It would be a good idea to have these modules installed:
|
||||
Storable, Date::Format,
|
||||
|
||||
You can easily check if these are installed by executing these two
|
||||
commands.
|
||||
|
||||
If the module is installed, you'll get no output:
|
||||
perl -e 'use Storable'
|
||||
perl -e 'use Date::Format'
|
||||
|
||||
|
||||
|
||||
*) Read the Policies and Overview documents found in this directory to
|
||||
help you get a feel for the scope of this installation.
|
||||
|
||||
*) The process id which receives and process the mail must be the the
|
||||
*) The process id which receives and process the mail must be the
|
||||
same id which runs the tinderbox cron job to prepare the web pages. I
|
||||
prefer to manage my webserver so that all CGI scripts do not run as
|
||||
the same user. Using one user id can cause security problems which
|
||||
@ -39,10 +48,10 @@ unix system users (daemon, nobody, bin) since this could cause
|
||||
security interactions with other programs which use these ids.
|
||||
|
||||
It may take some thought as to how the user id will be configured to
|
||||
run when recieving mail and when recieving web requests and not be a
|
||||
run when receiving mail and when receiving web requests and not be a
|
||||
user id which will cause security problems.
|
||||
|
||||
These products will help partion your web application to run as
|
||||
These products will help partition your web application to run as
|
||||
different users. (See http://www.w3.org/Security/Faq/wwwsf4.html for
|
||||
more info)
|
||||
|
||||
@ -99,7 +108,7 @@ scripts we must substitute some values into the source code to make it
|
||||
executable. You may wish to change the default directories in
|
||||
configure for some of the makefile variables. Please read config.out
|
||||
and make any changes which need to be made for your system. Configure
|
||||
also excepts command line options to change some default variables.
|
||||
also accepts command line options to change some default variables.
|
||||
Please look at the configure source code for variable details, but the
|
||||
most common changes are:
|
||||
|
||||
@ -143,7 +152,7 @@ can copy the *.cgi files to another directory if this is not the case.
|
||||
*) There are some gifs located in the gif directory which have
|
||||
historically been used by tinderbox. The installation via 'make
|
||||
install' does not install these images. Put them somewhere in your
|
||||
webservers html directory if you wish to use them. Samples of their
|
||||
webserver's html directory if you wish to use them. Samples of their
|
||||
use are in the configuration files.
|
||||
|
||||
*) set up a cron job to run $cgi-bin/bin/tinder.cgi --daemon-mode
|
||||
@ -159,10 +168,10 @@ incoming tinderbox mail. The process id which receives and process
|
||||
the mail must be the the same id which runs the tinderbox cron job to
|
||||
prepare the web pages. Usually this set up is accomplished by having
|
||||
the MTA (Sendmail) pass mail for particular accounts into a script.
|
||||
This can be configued via a global configuration file (Sendmail alias
|
||||
This can be configured via a global configuration file (Sendmail alias
|
||||
file) or via a .forward file (each account gets the same user id but a
|
||||
different home directory, each home directory gets a .forward to cause
|
||||
incomming mail to be delivered through the correct tinderbox mail
|
||||
incoming mail to be delivered through the correct tinderbox mail
|
||||
processing program).
|
||||
|
||||
I have used the following configurations for the mail server Postfix.
|
||||
@ -209,7 +218,7 @@ hostname/modules exactly as you wrote it in VCData. Then copy your
|
||||
~/.cvspass into the tinderbox server user id's home directory. This
|
||||
must be the REAL home of the Tinderbox daemon, as listed in
|
||||
/etc/passwd/ and set in the $HOME environmental variable for
|
||||
tinder.cgi. The file must not be world readble or writeable or
|
||||
tinder.cgi. The file must not be world readable or writable or
|
||||
executable.
|
||||
|
||||
|
||||
@ -234,7 +243,7 @@ mailing to changes in ticket state not updates (edit) of a ticket.
|
||||
*) Check that the time on your webserver, your version control
|
||||
machine, your bug tracking machine and your build machines are all in
|
||||
sync. Check that mail if build mail bounces on any of the above
|
||||
machines that it will be recieved by someone who can act on it.
|
||||
machines that it will be received by someone who can act on it.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -37,12 +37,16 @@ and you can separately version the local configurations which you
|
||||
make. It is also easy to see the local configurations since you have
|
||||
both the original and the modified code on the same server and can
|
||||
difference the two. As an example you might need to change the
|
||||
BuildStatus I assume that you have the following possible build
|
||||
BuildStatus - I assume that you have the following possible build
|
||||
outcomes (Build in progress, Build failed, Build succeded but tests
|
||||
failed, Build and all tests were successful) You may have additional
|
||||
outcomes to specifiy which kind of tests failed (unit test failed, not
|
||||
enough unit test coverage, performance tests failed). Similarly you may have unusual requirements for how the filesystem should be laied out. I provide a
|
||||
I suggest that you read through the files to see
|
||||
enough unit test coverage, performance tests failed). Similarly you
|
||||
may have unusual requirements for how the filesystem should be laied
|
||||
out. I provide a outcomes to specify which kind of tests failed (unit
|
||||
test failed, not enough unit test coverage, performance tests failed).
|
||||
Similarly you may have unusual requirements for how the filesystem
|
||||
should be laid out. I suggest that you read through the files to see
|
||||
how they are laid out and what types of changes are possible.
|
||||
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ policies you will need to set:
|
||||
To install tinderbox you will need some information about your
|
||||
existing computer systems and some idea about what your goals are.
|
||||
Here is a list of questions to help get you started, some of these
|
||||
ideas may not be apropriate for your environment.
|
||||
ideas may not be appropriate for your environment.
|
||||
|
||||
|
||||
The webserver will serve the tinderbox pages.
|
||||
@ -40,8 +40,8 @@ The same user id must be used for running the scripts as for tinderbox
|
||||
mail delivery. The Tinderbox Configuration files will define this
|
||||
user id and as a security precaution check that it is running as the
|
||||
required id. It is suggested that this id not be a privileged id
|
||||
(higher ids are better, please make this number be grater then 10 and
|
||||
bigger then 100 is recommended). Smaller ids are often assumed to
|
||||
(higher ids are better, please make this number be greater than 10 and
|
||||
bigger than 100 is recommended). Smaller ids are often assumed to
|
||||
have more privileges on a Unix box then larger ids. It is not a good
|
||||
idea for an unauthenticated user to have any privileges so a large id
|
||||
is recommended. It is also recommended that you not use the id 'nobody'
|
||||
|
||||
@ -13,7 +13,7 @@ javascript programs in tinderbox2/src/lib/HTMLPopUp/MozillaLayers.pm.
|
||||
Please keep the code neat and nicely indented.
|
||||
|
||||
I need to allow the VC system to have a daemon gather the VC
|
||||
information and pass it to tinderbox via the same update methods wich
|
||||
information and pass it to tinderbox via the same update methods which
|
||||
Builds uses. Then both the tinder.cgi and this new cvs process could
|
||||
be run out of cron periodically and the webpages would not be delayed
|
||||
if CVS takes a long time to respond this might improve the response
|
||||
@ -23,5 +23,5 @@ which was IO bound and one which was CPU bound.
|
||||
|
||||
It would be really nice if CVS could mail tinderbox the updates which
|
||||
apply to the branches of interest, then tinderbox would not have to
|
||||
pool and it would get the branch information which it needs.
|
||||
poll and it would get the branch information which it needs.
|
||||
|
||||
|
||||
@ -2,12 +2,12 @@
|
||||
# -*- Mode: perl; indent-tabs-mode: nil -*-
|
||||
#
|
||||
|
||||
# addnote.cgi - the webform which users enter notices to be displayed
|
||||
# addnote.cgi - the webform via which users enter notices to be
|
||||
# on the tinderbox status page.
|
||||
|
||||
|
||||
# $Revision: 1.21 $
|
||||
# $Date: 2003/06/18 16:11:00 $
|
||||
# $Revision: 1.22 $
|
||||
# $Date: 2003/08/04 17:14:56 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/bin/addnote.cgi,v $
|
||||
# $Name: $
|
||||
|
||||
@ -7,8 +7,8 @@
|
||||
# columns from being shown on the default pages.
|
||||
|
||||
|
||||
# $Revision: 1.23 $
|
||||
# $Date: 2002/05/03 03:29:14 $
|
||||
# $Revision: 1.24 $
|
||||
# $Date: 2003/08/04 17:14:57 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/bin/admintree.cgi,v $
|
||||
# $Name: $
|
||||
@ -65,11 +65,11 @@ use HTMLPopUp;
|
||||
# unexpectedly. Scripting tags that can be embedded in this way
|
||||
# include <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>.
|
||||
|
||||
# note that since we want some tags to be allowed (href) but not #
|
||||
# note that we want some tags to be allowed (href) but not #
|
||||
# others. This requirement breaks the taint perl mechanisms for #
|
||||
# checking as we can not escape every '<>'.
|
||||
|
||||
# However we trust our administrators not do put bad things in the web
|
||||
# However we trust our administrators not to put bad things in the web
|
||||
# pages and we wish to allow them to embed scripts.
|
||||
|
||||
|
||||
@ -475,7 +475,7 @@ sub change_ignore_builds {
|
||||
sub change_motd {
|
||||
my (@results) = ();
|
||||
|
||||
# remember new_motd could be empty. As long as it is different then
|
||||
# remember new_motd could be empty. As long as it is different than
|
||||
# old_motd we should save it.
|
||||
|
||||
($NEW_MOTD eq $CURRENT_MOTD) &&
|
||||
|
||||
@ -4,14 +4,14 @@
|
||||
|
||||
# gunzip.cgi - This cgi script will gunzip a file and send the result
|
||||
# to standard out in a form that a webserver can display. Filenames
|
||||
# are passed in via an abreviated form. It is assumed that all files
|
||||
# are passed in via an abbreviated form. It is assumed that all files
|
||||
# are either brief or full log files which are stored in known
|
||||
# Tinderbox directories. The file id is the basename of the file
|
||||
# without the '.gz.html' extension.
|
||||
|
||||
|
||||
# $Revision: 1.9 $
|
||||
# $Date: 2002/04/26 22:27:17 $
|
||||
# $Revision: 1.10 $
|
||||
# $Date: 2003/08/04 17:14:57 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/bin/gunzip.cgi,v $
|
||||
# $Name: $
|
||||
@ -80,7 +80,7 @@ Synopsis
|
||||
|
||||
This cgi script will gunzip a file and send the result to standard out
|
||||
in a form that a webserver can display. Filenames are passed in via
|
||||
an abreviated form. It is assumed that all files are either brief or
|
||||
an abbreviated form. It is assumed that all files are either brief or
|
||||
full log files which are stored in known Tinderbox directories. The
|
||||
file id is the basename of the file without the '.gz.html' extension.
|
||||
|
||||
|
||||
@ -5,10 +5,10 @@
|
||||
# processmail_bugs - The 'bug tracking' mail processing engine for
|
||||
# tinderbox. The bug tracking server (bugzilla, aim, remedy, etc.)
|
||||
# should send mail to the tinderbox server, when bug tickets change
|
||||
# state. This program will parse the most common mail formats and and
|
||||
# state. This program will parse the most common mail formats and
|
||||
# tell the tinderbox server about the the database column Vs value
|
||||
# pairs. This program should be run by the MTA (Sendmail,Fetchmail)
|
||||
# when ever mail for the tinderboxs bugtracking mail account arrives.
|
||||
# whenever mail for the tinderbox's bugtracking mail account arrives.
|
||||
# Tinderbox will display summary information about these tickets on
|
||||
# the same page as the build and version control information. This
|
||||
# program should not need any local configuration. All we assume is
|
||||
@ -23,8 +23,8 @@
|
||||
|
||||
|
||||
|
||||
# $Revision: 1.12 $
|
||||
# $Date: 2002/04/24 03:20:34 $
|
||||
# $Revision: 1.13 $
|
||||
# $Date: 2003/08/04 17:14:57 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/bin/processmail_bugs,v $
|
||||
# $Name: $
|
||||
@ -228,7 +228,7 @@ sub clean_bug_input {
|
||||
sub parse_bt_vars {
|
||||
|
||||
# Lines will be diffs, and this could cause the variables to appear
|
||||
# twice in the data with different vaules. We keep the LAST
|
||||
# twice in the data with different values. We keep the LAST
|
||||
# assignment of each variable. This means that long variables can
|
||||
# not be split up to multiple lines.
|
||||
|
||||
@ -269,7 +269,7 @@ sub parse_bt_vars {
|
||||
# We make a quick test to eliminate lines we do not want.
|
||||
|
||||
# The lines we want:
|
||||
# 1) begin with a capital letter (but may be preceeded by
|
||||
# 1) begin with a capital letter (but may be preceded by
|
||||
# diff characters).
|
||||
# 2) have a colon followed by a space followed by data in them.
|
||||
|
||||
@ -302,7 +302,7 @@ sub parse_bt_vars {
|
||||
# We make a quick test to eliminate lines we do not want.
|
||||
|
||||
# The lines we want:
|
||||
# 1) begin with a capital letter (but may be preceeded by
|
||||
# 1) begin with a capital letter (but may be preceded by
|
||||
# white space).
|
||||
# 2) have exactly two pipes in them.
|
||||
|
||||
@ -336,7 +336,7 @@ sub parse_bt_vars {
|
||||
|
||||
sub set_tinderbox_variables {
|
||||
|
||||
# set known tinderbox fields based on the bug trackers variables.
|
||||
# set known tinderbox fields based on the bug tracker's variables.
|
||||
my ($bug_id) = $TINDERBOX{$BTData::BUGID_FIELD_NAME};
|
||||
|
||||
$TINDERBOX{'tinderbox_timenow'} = time();
|
||||
@ -386,7 +386,7 @@ sub set_tinderbox_variables {
|
||||
$TINDERBOX{'tinderbox_tree'} = $tree;
|
||||
|
||||
# some updates do not have a status. We can not do anything with
|
||||
# them, and we probably only want to only report when the bug
|
||||
# them, and we probably only want to report when the bug
|
||||
# changes state anyway.
|
||||
|
||||
($TINDERBOX{'tinderbox_status'}) ||
|
||||
|
||||
@ -6,14 +6,14 @@
|
||||
# machines (clients) send their build logs to the server to report on
|
||||
# the status of the builds and this program accepts the mail (via an
|
||||
# MTA like sendmail) and acts as the MDA (mail delivery agent). This
|
||||
# program process the build logs for the tinderbox server (tinder.cgi)
|
||||
# and enforms the server of any status updates. It also stores the
|
||||
# program processes the build logs for the tinderbox server (tinder.cgi)
|
||||
# and informs the server of any status updates. It also stores the
|
||||
# logs in compressed form for future references by the tinderbox
|
||||
# server. No locks are used by the mail processes, data is passed to
|
||||
# the tinderbox server in a maildir like format.
|
||||
|
||||
# $Revision: 1.31 $
|
||||
# $Date: 2003/04/20 20:28:11 $
|
||||
# $Revision: 1.32 $
|
||||
# $Date: 2003/08/04 17:14:58 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/bin/processmail_builds,v $
|
||||
# $Name: $
|
||||
@ -86,19 +86,19 @@ Informational Arguments
|
||||
|
||||
--force-time Ignore the: 'starttime', 'timenow' attributes of the mail
|
||||
message and set new ones based off the current time. This
|
||||
option is to allow for easier testing the functionality of
|
||||
the program. This flag is not recomended for production use.
|
||||
option is to allow for easier testing the functionality of
|
||||
the program. This flag is not recommended for production use.
|
||||
|
||||
--skip-check Turn off the strict checking of input files, to allow for
|
||||
easier testing the functionality of the program. This flag is
|
||||
not recomended for production use.
|
||||
not recommended for production use.
|
||||
|
||||
|
||||
Synopsis
|
||||
|
||||
|
||||
This program handles mail acceptance for the tinderbox system. The
|
||||
mail transerfer agent runs this program to deliver the mail. Mail is
|
||||
mail transfer agent runs this program to deliver the mail. Mail is
|
||||
recived on stdin, this makes it particularly easy to test this script.
|
||||
The script accepts no arguments and will exit with return code of zero
|
||||
if successful.
|
||||
@ -110,7 +110,7 @@ is written to the error log and standard err.
|
||||
Mail is expected to consist of
|
||||
|
||||
1) A set of tinderbox variables with values applicable to this
|
||||
build this includes information on which regular expressions
|
||||
build. This includes information on which regular expressions
|
||||
to use when parsing the build log and whether the build was
|
||||
successful or not.
|
||||
|
||||
@ -131,7 +131,7 @@ information extracted from the mail message and any new variables
|
||||
derived while parsing the log file.
|
||||
|
||||
The build logs are converted into HTML and are split into full and
|
||||
summary form and stored on the disk. Both logs basnames are the same
|
||||
summary form and stored on the disk. Both logs basenames are the same
|
||||
unique id which is found by using the time this program was stared and
|
||||
its pid. The logs are stored in separate directories and compressed.
|
||||
The server knows how to contruct URLS to the log files because that
|
||||
@ -141,7 +141,7 @@ file is written to the disk with a unique name. No locks are held by
|
||||
this code.
|
||||
|
||||
Builds which take a long time to complete can send multiple status
|
||||
mails each one conaining the log file which has been completed so far.
|
||||
mails each one containing the log file which has been completed so far.
|
||||
All mails sent before the build is finished should have the status
|
||||
'building'. The last mail must contain the results of the build. The
|
||||
website will make each build log available so that everyone can see
|
||||
@ -159,7 +159,7 @@ variable must be 'END'. We ignore the line following the variables,
|
||||
it should be blank. Tinderbox variables are specified by a line which
|
||||
looks like this string:
|
||||
|
||||
tinderbox: variablename: varaiblevalue
|
||||
tinderbox: variablename: variablevalue
|
||||
|
||||
Any uuencoded binaries in the mail message are extracted and uudecoded
|
||||
and stored on disk in the filename specified by the tinderbox variable
|
||||
@ -171,7 +171,7 @@ customized with the set of regular expressions which describe the
|
||||
errors which are produced as part of the build process. These regular
|
||||
expressions are stored in the module Error_Parse.pm. Each mail
|
||||
contains the tinderbox variable 'errorparser' which chooses one set of
|
||||
regualar expressions to use when processing the mails contents.
|
||||
regular expressions to use when processing the mail's contents.
|
||||
|
||||
|
||||
Tinderbox Variables:
|
||||
@ -180,7 +180,7 @@ Tinderbox variables are name/value pairs which appear at the top of
|
||||
the mail message. Lines can appear in any order but END should be the
|
||||
last line followed by one blank line. If the tinderbox variable name
|
||||
is repeated on different lines, then its value is taken to be the
|
||||
concatination of all values listed.
|
||||
concatenation of all values listed.
|
||||
|
||||
The required tinderbox variable:
|
||||
|
||||
@ -251,7 +251,7 @@ TinderboxPrint:
|
||||
Arbitrary links and text can be embedded in the tinderbox build
|
||||
cells. Any log file which contains a line beginning with
|
||||
"TinderboxPrint: " will be copied into the build cell. If you are
|
||||
ebedding links, you should put exactly one link per TinderboxPrint
|
||||
embedding links, you should put exactly one link per TinderboxPrint
|
||||
command since the links are checked to ensure that they are well
|
||||
formed. Here are some examples of embedded performance numbers (and
|
||||
links to the web page relevant to these numbers) from one mozilla
|
||||
@ -284,7 +284,7 @@ The files are found in the directories
|
||||
|
||||
Files:
|
||||
|
||||
File names for the output files are contructed from the values returned by:
|
||||
File names for the output files are constructed from the values returned by:
|
||||
|
||||
FileStructure::get_filename(\$tree, 'brief-log')
|
||||
FileStructure::get_filename(\$tree, 'build_bin_dir')
|
||||
@ -312,7 +312,7 @@ Time Format
|
||||
|
||||
Most OS have an internal time format of "seconds since the epoch".
|
||||
This format is easiest to use if all your machines have the same OS or
|
||||
if you standarize on some epoch for the purposes of tinderbox
|
||||
if you standardize on some epoch for the purposes of tinderbox
|
||||
mails. Times can also be given in the format "MM/DD/YY HH:MM:SS" if
|
||||
this is more convenient.
|
||||
|
||||
@ -459,7 +459,7 @@ sub backward_compatibility {
|
||||
|
||||
=pod
|
||||
|
||||
"errorparser" is a bad name, we want a "buildtools" which discribes
|
||||
"errorparser" is a bad name, we want a "buildtools" which describes
|
||||
the compilers and make programs. The buildtools module is shared with
|
||||
the buildscript and the logparser. We might want to have the
|
||||
configure output drive the choice of errorparser or tell configure
|
||||
@ -477,7 +477,7 @@ current time on client within 10 minutes.
|
||||
need to check that this update either
|
||||
|
||||
1) has the same starttime as the last update of this tree/build
|
||||
2) has a starttime grater then min time between builds.
|
||||
2) has a starttime greater then min time between builds.
|
||||
|
||||
=cut
|
||||
;
|
||||
@ -542,7 +542,7 @@ sub check_required_vars {
|
||||
|
||||
# Note at this point we could have sourced only the implementation
|
||||
# of the error parser that we need. I think programs which use an
|
||||
# autoload for libaraies are messy since they cause variable run
|
||||
# autoload for libraraies are messy since they cause variable run
|
||||
# time requirements.
|
||||
|
||||
$TINDERBOX{'timenow'} = main::extract_digits($TINDERBOX{'timenow'});
|
||||
@ -580,7 +580,7 @@ sub check_required_vars {
|
||||
} else {
|
||||
$err_string .= (
|
||||
"Variable: 'tinderbox: starttime:',".
|
||||
" is grater then the tinderbox: timenow.\n".
|
||||
" is greater than the tinderbox: timenow.\n".
|
||||
"starttime: $TINDERBOX{'starttime'}, ".
|
||||
"timenow: $TINDERBOX{'timenow'}".
|
||||
"\n".
|
||||
@ -634,7 +634,7 @@ sub format_bloat_delta {
|
||||
sub process_bloat_data {
|
||||
my ($line, $func_line_type,) = @_;
|
||||
|
||||
# we have to call &highlight_errors() even thought there are no
|
||||
# we have to call &highlight_errors() even though there are no
|
||||
# errors, or the line numbers will get messed up
|
||||
|
||||
my ($line_type) = &$func_line_type($line);
|
||||
@ -837,7 +837,7 @@ sub parse_mail_body {
|
||||
# FULL: a complete copy of the logfile with HTML markup.
|
||||
# BRIEF: contains only the error messages with some lines of
|
||||
# surrounding context and HTML markup.
|
||||
# ERROR_PICK: a list of html links to error messages, this will apear
|
||||
# ERROR_PICK: a list of html links to error messages, this will appear
|
||||
# on the top of both brief and full when our
|
||||
# processing is complete.
|
||||
|
||||
@ -922,8 +922,8 @@ sub parse_mail_body {
|
||||
my $print = $1;
|
||||
|
||||
# Long lines might get split by mailing software but then we
|
||||
# can't reconstitute it, since we will not know how many lines
|
||||
# to take. Make sure refs, if they exist, are closed;
|
||||
# can't reconstitute them, since we will not know how many
|
||||
# lines to take. Make sure refs, if they exist, are closed;
|
||||
|
||||
my $good_line = (
|
||||
($print !~ m!<\s*a\s+!i) ||
|
||||
@ -1011,9 +1011,9 @@ sub parse_mail_body {
|
||||
|
||||
} # while
|
||||
|
||||
# We always want to see the very last line of the build, wether or
|
||||
# We always want to see the very last line of the build, whether or
|
||||
# not the build failed. So treat the last line like an error and
|
||||
# print the context surronding it.
|
||||
# print the context surrounding it.
|
||||
|
||||
my ($lines_context) = min( ($lines_since_error - $Error_Parse::LINES_AFTER_ERROR - 2),
|
||||
$Error_Parse::LINES_BEFORE_ERROR);
|
||||
@ -1076,7 +1076,7 @@ sub parse_mail_body {
|
||||
|
||||
sub assemble_files {
|
||||
|
||||
# piece together the permanent files from the temparary ones.
|
||||
# piece together the permanent files from the temporary ones.
|
||||
|
||||
# much of this could be done in shell scripts (cat) but we have more
|
||||
# error control in perl and it is more portable to non-unix OS.
|
||||
@ -1089,11 +1089,11 @@ sub assemble_files {
|
||||
# append the headers to the top of the full log and compress the result
|
||||
|
||||
open(ERROR_PICK, "<$TMP_FILE{'errorpick'}") ||
|
||||
die("Could not write to file: '$TMP_FILE{'errorpick'}'.\n");
|
||||
die("Could not read from file: '$TMP_FILE{'errorpick'}'.\n");
|
||||
open(TMP_FULL, "<$TMP_FILE{'full-log'}") ||
|
||||
die("Could not write to file: '$TMP_FILE{'full-log'}'.\n");
|
||||
die("Could not read from file: '$TMP_FILE{'full-log'}'.\n");
|
||||
open(FULL, ">$FILE{'full-log'}") ||
|
||||
die("Could not write to file: '$TMP_FILE{'full-log'}'.\n");
|
||||
die("Could not write to file: '$FILE{'full-log'}'.\n");
|
||||
|
||||
print FULL log_header('full');
|
||||
|
||||
@ -1108,7 +1108,7 @@ sub assemble_files {
|
||||
print FULL log_footer('full');
|
||||
|
||||
close(FULL) ||
|
||||
die("Could not close file: '$FILE{'full-log'}': waitstaus: $? : $! \n");
|
||||
die("Could not close file: '$FILE{'full-log'}': waitstatus: $? : $! \n");
|
||||
close(TMP_FULL) ||
|
||||
die("Could not close file: '$TMP_FILE{'full-log'}': $! \n");
|
||||
close(ERROR_PICK) ||
|
||||
@ -1120,11 +1120,11 @@ sub assemble_files {
|
||||
# append the headers to the top of the brief log
|
||||
|
||||
open(ERROR_PICK, "<$TMP_FILE{'errorpick'}") ||
|
||||
die("Could not write to file: '$TMP_FILE{'errorpick'}'.\n");
|
||||
die("Could not read from file: '$TMP_FILE{'errorpick'}'.\n");
|
||||
open(TMP_BRIEF, "<$TMP_FILE{'brief-log'}") ||
|
||||
die("Could not write to file: '$TMP_FILE{'brief-log'}'.\n");
|
||||
die("Could not read from file: '$TMP_FILE{'brief-log'}'.\n");
|
||||
open(BRIEF, ">$FILE{'brief-log'}") ||
|
||||
die("Could not write to file: '$TMP_FILE{'brief-log'}'.\n");
|
||||
die("Could not write to file: '$FILE{'brief-log'}'.\n");
|
||||
|
||||
print BRIEF log_header('brief');
|
||||
|
||||
|
||||
@ -6,8 +6,8 @@
|
||||
# days set in TinderConfig. This program should be
|
||||
# run from cron daily.
|
||||
|
||||
# $Revision: 1.8 $
|
||||
# $Date: 2001/10/10 15:06:48 $
|
||||
# $Revision: 1.9 $
|
||||
# $Date: 2003/08/04 17:14:58 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/bin/rmlogs,v $
|
||||
# $Name: $
|
||||
@ -103,7 +103,7 @@ sub rm_old_logs {
|
||||
my (@trees) = TreeData::get_all_trees();
|
||||
my (%dirs) = ();
|
||||
|
||||
# find the set of directories to search. We one to raverse each
|
||||
# find the set of directories to search. We want to traverse each
|
||||
# directory only once even if it is used for multiple trees.
|
||||
|
||||
foreach $tree (@trees) {
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
# -*- Mode: perl; indent-tabs-mode: nil -*-
|
||||
#
|
||||
|
||||
# $Revision: 1.32 $
|
||||
# $Date: 2003/05/10 20:03:16 $
|
||||
# $Revision: 1.33 $
|
||||
# $Date: 2003/08/04 17:14:59 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/bin/tinder.cgi,v $
|
||||
# $Name: $
|
||||
@ -103,7 +103,7 @@ CGI Mode Arguments
|
||||
at time --start-time. If --end-time and --display-hours
|
||||
are not set the default --display-hours is: $DEFAULT_DISPLAY_HOURS.
|
||||
This argument is only effective if --end-time is not set.
|
||||
Both --end-time and --display-hours are equivlant means
|
||||
Both --end-time and --display-hours are equivalent means
|
||||
of stating when the table should end.
|
||||
|
||||
--noignore Show all build columns even if some of them
|
||||
@ -121,12 +121,11 @@ Daemon Mode Arguments
|
||||
Synopsis
|
||||
|
||||
This program generates the Tinderbox Web pages. It can be run either
|
||||
in deamon mode via a cron job or via a webserver as a regular cgi bin
|
||||
in daemon mode via a cron job or via a webserver as a regular cgi bin
|
||||
program.
|
||||
|
||||
In daemon mode the program will update all the databases with current
|
||||
data and and prepare new summary pages and status pages for all
|
||||
trees.
|
||||
data and prepare new summary pages and status pages for all trees.
|
||||
|
||||
In CGI mode the program will prepare the status page that the user
|
||||
asked for, this page is not saved to disk and we update none of the
|
||||
@ -134,8 +133,7 @@ databases. This requires the user to specify a single tree which the
|
||||
page will represent and pass in any additional arguments which the
|
||||
user wishes to be different from the defaults.
|
||||
|
||||
New data is pushed into the via administrative web forms and via mail
|
||||
which is delivered to the helper program process mail and has the
|
||||
New data is pushed into the system via administrative web forms and
|
||||
specified format. Additional data is gathed by having the program
|
||||
query the Version Control Software to find any updates which have
|
||||
happend recently.
|
||||
|
||||
@ -69,7 +69,7 @@ tinderbox: buildfamily: unix
|
||||
3) Perform the build, saving the output to a log file.
|
||||
|
||||
4) Determine if the build was successful or failed. This could be done either
|
||||
by checking for the presence of a binary, or being using error codes returned
|
||||
by checking for the presence of a binary, or by using error codes returned
|
||||
from the compile command.
|
||||
|
||||
5) Send a completion message to Tinderbox, identifying build success or
|
||||
|
||||
@ -32,8 +32,8 @@
|
||||
# complete rewrite by Ken Estes, Mail.com (kestes@staff.mail.com).
|
||||
# Contributor(s):
|
||||
|
||||
# $Revision: 1.14 $
|
||||
# $Date: 2002/01/02 18:09:59 $
|
||||
# $Revision: 1.15 $
|
||||
# $Date: 2003/08/04 17:15:02 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Name: $
|
||||
|
||||
@ -129,7 +129,7 @@ software and the developer provided scripts which perform the build
|
||||
(Makefiles, configuration scripts, developer provided build scripts).
|
||||
Developers are responsible for ensuring that they keep their project
|
||||
related build scripts up to date so that the build interface does not
|
||||
change too rapidly. The for a given project the build should always
|
||||
change too rapidly. Then for a given project the build should always
|
||||
be performed using the same commands and any complex build processing
|
||||
should be performed inside developer maintained scripts (shell, perl
|
||||
Makefile).
|
||||
@ -215,14 +215,14 @@ sub set_static_vars {
|
||||
# to deliver mail directly if the build is running on the same
|
||||
# machine as the server.
|
||||
|
||||
$MAILER = '/usr/lib/sendmail -t';
|
||||
$MAILER = '/usr/lib/sendmail -oi -t';
|
||||
|
||||
$ERROR_LOG= "/var/log/tinderbox2/build.log";
|
||||
|
||||
$BUILDCF = "buildcf";
|
||||
|
||||
# minimum time between the start of consecutive builds. Tinderbox
|
||||
# requires this to be grater then 5 minutes.
|
||||
# requires this to be greater then 5 minutes.
|
||||
|
||||
$MINIMUM_BUILD_SECONDS = 8*60;
|
||||
|
||||
@ -438,10 +438,10 @@ sub set_server_args {
|
||||
($ADMINISTRATOR) ||
|
||||
die("Must define a build administrator.\n");
|
||||
|
||||
($MAIL_FROM) ||
|
||||
($MAIL_TO) ||
|
||||
die("Must define a mailing address to send builds to.\n");
|
||||
|
||||
($MAIL_TO) ||
|
||||
($MAIL_FROM) ||
|
||||
die("Must define an account to have the builds be sent from.\n");
|
||||
|
||||
|
||||
@ -529,14 +529,6 @@ EOF
|
||||
|
||||
$message =~ s/([^\n]{$MAX_MAIL_LINE_LEN})/$1\n/g;
|
||||
|
||||
# If any line is a dot on a line by itself, replace
|
||||
# that with a blank line. This is to prevent cases
|
||||
# where a <cr>.<cr> occurs in the log file. Sendmail
|
||||
# interprets that as the end of the mail, and
|
||||
# truncates the log before it gets to Tinderbox.
|
||||
|
||||
$message =~ s/^\.$/\.\./mg;
|
||||
|
||||
# If we are testing then @CMD_LOG contains the list of commands we
|
||||
# would have executed. This is where they get printed. We do not
|
||||
# need to mail the tinderbox server because the log is really
|
||||
@ -639,9 +631,9 @@ sub system3 {
|
||||
@{$args{'cmd_vec'}}
|
||||
);
|
||||
|
||||
# this check should be redundant but better safe then sorry
|
||||
# this check should be redundant but better safe than sorry
|
||||
($child_pid) ||
|
||||
die ("Open3() did not start: '@{$cmd}'. $!\n");
|
||||
die ("Open3() did not start: '@{$args{cmd_vec}'. $!\n");
|
||||
|
||||
close($fh_in) ||
|
||||
die("Could not close child stdin: $!\n");
|
||||
@ -828,7 +820,7 @@ sub run_shell_commands {
|
||||
|
||||
|
||||
|
||||
# This function ensures that build do not start too frequently. It
|
||||
# This function ensures that builds do not start too frequently. It
|
||||
# will sleep if and only if the last build finished too quickly.
|
||||
|
||||
sub slow_build_speed {
|
||||
|
||||
@ -24,8 +24,8 @@
|
||||
# variables substituted.
|
||||
|
||||
|
||||
# $Revision: 1.7 $
|
||||
# $Date: 2002/04/25 00:55:49 $
|
||||
# $Revision: 1.8 $
|
||||
# $Date: 2003/08/04 17:15:02 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/clientbin/generic.sample.buildcf,v $
|
||||
# $Name: $
|
||||
@ -73,7 +73,7 @@ use TreeData;
|
||||
# User configurable variables live in their own namespace so that they
|
||||
# will not contaminate the build script. The buildscript will get the
|
||||
# values it needs via well known functions. This package may also set
|
||||
# %ENV to effect the build programs.
|
||||
# %ENV to affect the build programs.
|
||||
|
||||
|
||||
|
||||
@ -323,7 +323,7 @@ $BUILDS = {
|
||||
], # end lint
|
||||
|
||||
|
||||
}; # end %BUILDS
|
||||
}; # end $BUILDS
|
||||
|
||||
return $BUILDS;
|
||||
}
|
||||
@ -377,7 +377,7 @@ sub build_name {
|
||||
sub build_administrator {
|
||||
my (%args) = @_;
|
||||
|
||||
return "your.mailing.addres\@company.com";
|
||||
return "your.mailing.address\@company.com";
|
||||
}
|
||||
|
||||
# addressing information for the build messages
|
||||
|
||||
@ -1,17 +1,17 @@
|
||||
# -*- Mode: perl; indent-tabs-mode: nil -*-
|
||||
|
||||
# mozilla.uinx.buildcf - this is an example buildcf which looks
|
||||
# mozilla.unix.buildcf - this is an example buildcf which looks
|
||||
# similar to the way in which the original tinderbox build clients
|
||||
# work. It is untested and may not actually work but gives an idea
|
||||
# how I envision the buildcf working. This configuration file shows
|
||||
# what I believe belongs in the the build script and what part of the
|
||||
# original build script should be moved to the Makefile. Run --test to
|
||||
# see the completed build script which has all the vairiables
|
||||
# see the completed build script which has all the variables
|
||||
# substituted.
|
||||
|
||||
|
||||
# $Revision: 1.3 $
|
||||
# $Date: 2002/05/03 20:20:44 $
|
||||
# $Revision: 1.4 $
|
||||
# $Date: 2003/08/04 17:15:02 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/clientbin/mozilla.unix.buildcf,v $
|
||||
# $Name: $
|
||||
@ -104,7 +104,7 @@ sub GetSystemInfo {
|
||||
# The environmental variables for building at mozilla/netscape are
|
||||
# quite complicated, your needs may be much simpler. Putting all
|
||||
# environmental variable differences into a single function makes it
|
||||
# clearer exactly how the environment differes on different platforms.
|
||||
# clearer exactly how the environment differs on different platforms.
|
||||
|
||||
sub build_environment{
|
||||
|
||||
@ -282,7 +282,7 @@ sub build_scripts {
|
||||
|
||||
|
||||
|
||||
# builds discribe a sequence of steps needed to perform a "build".
|
||||
# builds describe a sequence of steps needed to perform a "build".
|
||||
# Each build either succeeds or fails. Builds can be used for running
|
||||
# tests and checking source code style in addition to creating binaries.
|
||||
|
||||
@ -302,12 +302,12 @@ sub build_scripts {
|
||||
|
||||
# Each phase must have the following entries:
|
||||
|
||||
# phase_name: which discribes what the phase is.
|
||||
# phase_name: discribes what the phase is.
|
||||
|
||||
# error_status: the tinderbox status which should be returned
|
||||
# if the phase fails.
|
||||
|
||||
# script: a list of shell commands to be exectued in order
|
||||
# script: a list of shell commands to be exected in order
|
||||
# until one fails (each command in a separate shell, similar to make).
|
||||
|
||||
# dir: the directory which will be local while the script is
|
||||
|
||||
@ -4,8 +4,8 @@
|
||||
# Tracking system and its relationship to the tinderbox trees.
|
||||
|
||||
|
||||
# $Revision: 1.11 $
|
||||
# $Date: 2002/05/09 03:10:40 $
|
||||
# $Revision: 1.12 $
|
||||
# $Date: 2003/08/04 17:15:04 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/default_conf/BTData.pm,v $
|
||||
# $Name: $
|
||||
@ -42,8 +42,8 @@
|
||||
# list of field names) and that a subset of the fields will be of
|
||||
# interest to the tinderbox users (tinderbox is not the correct place
|
||||
# to display any sort of long comment field). Tinderbox will display
|
||||
# the bug number and a popup window showing relevant fields discribing
|
||||
# this bug. If the users wishes more information they may click on
|
||||
# the bug number and a popup window showing relevant fields describing
|
||||
# this bug. If the user wishes more information they may click on
|
||||
# the link and be taken directly to the bugtracking system for more
|
||||
# information about the bug. Bugs have their state change as the bug
|
||||
# is worked on and users of tinderbox wish to see information about
|
||||
|
||||
@ -5,8 +5,8 @@
|
||||
# errors and creating links into the source code where the errors
|
||||
# occurred.
|
||||
|
||||
# $Revision: 1.14 $
|
||||
# $Date: 2002/05/07 20:01:44 $
|
||||
# $Revision: 1.15 $
|
||||
# $Date: 2003/08/04 17:15:05 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/default_conf/Error_Parse.pm,v $
|
||||
# $Name: $
|
||||
@ -58,7 +58,7 @@ $VERSION = '#tinder_version#';
|
||||
# particular types of builds.
|
||||
|
||||
# If new types are added try and keep to a small set of colors or the
|
||||
# display will get confusing. You may find it convienent to keep a
|
||||
# display will get confusing. You may find it convenient to keep a
|
||||
# distinction between different kinds of warnings or different kinds
|
||||
# of tests but all warnings and all tests get the same color.
|
||||
|
||||
@ -419,7 +419,7 @@ compilers on NT and vice versa.
|
||||
|
||||
=item line_type
|
||||
|
||||
returns a string discribing if the line has any errors or warnings.
|
||||
returns a string describing if the line has any errors or warnings.
|
||||
The list of types may grow in the future as some warnings become more
|
||||
important then others. The possible return codes are:
|
||||
|
||||
|
||||
@ -6,8 +6,8 @@
|
||||
# tinderbox trees.
|
||||
|
||||
|
||||
# $Revision: 1.3 $
|
||||
# $Date: 2002/01/29 01:11:10 $
|
||||
# $Revision: 1.4 $
|
||||
# $Date: 2003/08/04 17:15:07 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/default_conf/ReqData.pm,v $
|
||||
# $Name: $
|
||||
@ -44,7 +44,7 @@
|
||||
# list of field names) and that a subset of the fields will be of
|
||||
# interest to the tinderbox users (tinderbox is not the correct place
|
||||
# to display any sort of long comment field). Tinderbox will display
|
||||
# the bug number and a popup window showing relevant fields discribing
|
||||
# the bug number and a popup window showing relevant fields describing
|
||||
# this bug. If the users wishes more information they may click on
|
||||
# the link and be taken directly to the bugtracking system for more
|
||||
# information about the bug. Bugs have their state change as the bug
|
||||
|
||||
@ -5,8 +5,8 @@
|
||||
# customizable settings.
|
||||
|
||||
|
||||
# $Revision: 1.47 $
|
||||
# $Date: 2003/05/26 14:26:05 $
|
||||
# $Revision: 1.48 $
|
||||
# $Date: 2003/08/04 17:15:07 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/default_conf/TinderConfig.pm,v $
|
||||
# $Name: $
|
||||
@ -50,6 +50,7 @@ package TinderConfig;
|
||||
|
||||
$ENV{'PATH'}= (
|
||||
'/bin'.
|
||||
':/home/kestes/mozilla/webtools/tinderbox2/build/test/vcsim'.
|
||||
':/usr/bin'.
|
||||
':/usr/local/bin'.
|
||||
':/opt/gnu/bin/'.
|
||||
@ -76,6 +77,8 @@ $ENV{'PATH'}= (
|
||||
|
||||
$TINDERBOX_UID=3310;
|
||||
$TINDERBOX_GID=3310;
|
||||
$TINDERBOX_UID=500;
|
||||
$TINDERBOX_GID=100;
|
||||
|
||||
# The url to the tinderbox server binary directory
|
||||
|
||||
@ -85,12 +88,14 @@ $URL_BIN = "http://lounge.mozilla.org/cgi-bin/cgiwrap/cgiwrap_exe/tbox";
|
||||
# The url to the tinderbox server HTML directory
|
||||
|
||||
$URL_HTML = "http://lounge.mozilla.org/tinderbox2";
|
||||
$URL_HTML = "file:///tmp/tinderbox2";
|
||||
|
||||
# The full path name tinderbox will use to access the tinderbox
|
||||
# servers root data directory where the html will be written.
|
||||
|
||||
#$TINDERBOX_HTML_DIR = "/home/httpd/html/tinderbox";
|
||||
$TINDERBOX_HTML_DIR = "/opt/apache/htdocs/tinderbox2";
|
||||
$TINDERBOX_HTML_DIR = "/tmp/tinderbox2";
|
||||
|
||||
# The full path name tinderbox will use to access the tinderbox
|
||||
# servers root data directory where the data will be written. For
|
||||
@ -104,6 +109,7 @@ $TINDERBOX_HTML_DIR = "/opt/apache/htdocs/tinderbox2";
|
||||
#$TINDERBOX_DATA_DIR = "/home/httpd/html/tinderbox";
|
||||
#$TINDERBOX_DATA_DIR = "/var/spool/tinderbox";
|
||||
$TINDERBOX_DATA_DIR = "/export2/tbox2-data";
|
||||
$TINDERBOX_DATA_DIR = "/tmp/tinderbox2/tbox2-data";
|
||||
|
||||
# Where to store the compressed HTML converted log files. Typically
|
||||
# this is either the DATA_DIR or the HTML dir, though it can be
|
||||
@ -131,11 +137,13 @@ $GLOBAL_INDEX_FILE = "index.html";
|
||||
# 'header_background_gif'.
|
||||
|
||||
$GIF_URL = 'http://lounge.mozilla.org/tinderbox2/gif';
|
||||
$GIF_URL = 'file:////home/kestes/mozilla/webtools/tinderbox2/src/gif/';
|
||||
|
||||
|
||||
# Error log filename:
|
||||
|
||||
$ERROR_LOG = "/var/log/tinderbox2/tinderbox2.log";
|
||||
$ERROR_LOG = "/tmp/tinderbox2/tinderbox2.log";
|
||||
|
||||
# Where the daemon mode lock (for all trees) is placed
|
||||
$LOCK_FILE = $TINDERBOX_HTML_DIR."/tinderd.lock";
|
||||
@ -199,12 +207,12 @@ $PopUpImpl = (
|
||||
# still have notices appear, they will just appear in the
|
||||
# other columns.
|
||||
|
||||
# 'TinderDB::Notice',
|
||||
'TinderDB::Notice',
|
||||
|
||||
# version control systems
|
||||
|
||||
# 'TinderDB::VC_CVS',
|
||||
'TinderDB::VC_Bonsai',
|
||||
'TinderDB::VC_CVS',
|
||||
# 'TinderDB::VC_Bonsai',
|
||||
# 'TinderDB::VC_Perforce',
|
||||
|
||||
'TinderDB::Build',
|
||||
@ -306,7 +314,7 @@ $ADD_TEXT_BROWSER_STRINGS = 0;
|
||||
# the version control system so use the generic version
|
||||
# if you do not use bonsai.
|
||||
|
||||
# 'TinderHeader::TreeState',
|
||||
'TinderHeader::TreeState',
|
||||
|
||||
# Get states from Bonsai tool and set the Bonsai states via
|
||||
# Tinderbox admin page.
|
||||
@ -318,7 +326,7 @@ $ADD_TEXT_BROWSER_STRINGS = 0;
|
||||
# known only to Tinderbox which can be set on our pages
|
||||
# and which override Bonsai for Tinderboxes use.
|
||||
|
||||
'TinderHeader::TreeState_Bonsai_Plus',
|
||||
# 'TinderHeader::TreeState_Bonsai_Plus',
|
||||
|
||||
);
|
||||
|
||||
@ -347,8 +355,8 @@ $ADD_TEXT_BROWSER_STRINGS = 0;
|
||||
# have time not to investigate it.
|
||||
|
||||
$VCDisplayImpl = (
|
||||
#'VCDisplay::None',
|
||||
'VCDisplay::Bonsai',
|
||||
'VCDisplay::None',
|
||||
#'VCDisplay::Bonsai',
|
||||
#'VCDisplay::Perforce_P4DB',
|
||||
);
|
||||
|
||||
@ -379,7 +387,7 @@ $PersistenceImpl = (
|
||||
# which the error parser found in the build logs? Use zero for no one
|
||||
# for yes.
|
||||
|
||||
$DISPLAY_BUILD_ERRORS = 0;
|
||||
$DISPLAY_BUILD_ERRORS = 1;
|
||||
|
||||
# If you your using one of the VCDisplay modules we need to know how
|
||||
# to make HTML to point to the bonsai CGI programs. We do not need to
|
||||
|
||||
@ -29,8 +29,8 @@
|
||||
# issue to work out.
|
||||
|
||||
|
||||
# $Revision: 1.19 $
|
||||
# $Date: 2003/05/26 13:57:08 $
|
||||
# $Revision: 1.20 $
|
||||
# $Date: 2003/08/04 17:15:07 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/default_conf/TreeData.pm,v $
|
||||
# $Name: $
|
||||
@ -176,30 +176,30 @@ $VERSION = '#tinder_version#';
|
||||
|
||||
# # these are dummy trees for testing.
|
||||
#
|
||||
# 'Project_A' => {
|
||||
# root => '/cvsroot',
|
||||
# module => '',
|
||||
# branch => 'HEAD',
|
||||
# },
|
||||
# 'Project_B' => {
|
||||
# root => '/cvsroot',
|
||||
# module => 'MozillaTinderboxAll',
|
||||
# branch => 'HEAD',
|
||||
# },
|
||||
# 'Project_C' => {
|
||||
# root => '/cvsroot',
|
||||
# module => 'NSS',
|
||||
# branch => 'HEAD',
|
||||
# },
|
||||
'Project_A' => {
|
||||
root => '/cvsroot',
|
||||
module => '',
|
||||
branch => 'HEAD',
|
||||
},
|
||||
'Project_B' => {
|
||||
root => '/cvsroot',
|
||||
module => 'MozillaTinderboxAll',
|
||||
branch => 'HEAD',
|
||||
},
|
||||
'Project_C' => {
|
||||
root => '/cvsroot',
|
||||
module => 'NSS',
|
||||
branch => 'HEAD',
|
||||
},
|
||||
|
||||
|
||||
# ------------- Real Trees Go Here ----------
|
||||
#
|
||||
|
||||
'SeaMonkey' => {
|
||||
root => '/cvsroot',
|
||||
module => 'MozillaTinderboxAll',
|
||||
branch => 'HEAD',
|
||||
# 'SeaMonkey' => {
|
||||
# root => '/cvsroot',
|
||||
# module => 'MozillaTinderboxAll',
|
||||
# branch => 'HEAD',
|
||||
|
||||
# If you are using Perforce use perforce filespec
|
||||
# to specify branche/module pairs. Perforce blurs
|
||||
@ -230,7 +230,7 @@ $VERSION = '#tinder_version#';
|
||||
|
||||
# branch => '//releases/v2.5',
|
||||
# module => '/webmodule/...',
|
||||
},
|
||||
# },
|
||||
|
||||
|
||||
);
|
||||
|
||||
@ -7,8 +7,8 @@
|
||||
# module which uses this library is: lib/TinderDB/VC_Bonsai.pm
|
||||
|
||||
|
||||
# $Revision: 1.13 $
|
||||
# $Date: 2002/05/09 18:16:56 $
|
||||
# $Revision: 1.14 $
|
||||
# $Date: 2003/08/04 17:15:10 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/BonsaiData.pm,v $
|
||||
# $Name: $
|
||||
@ -109,7 +109,7 @@ sub load_bonsai_libs {
|
||||
|
||||
$^W = 0;
|
||||
|
||||
# we should not depend on any directory being mounted, we are a deamon.
|
||||
# we should not depend on any directory being mounted, we are a daemon.
|
||||
chdir ("/") ||
|
||||
die("Could not cd to /. $!\n");
|
||||
|
||||
@ -276,7 +276,7 @@ sub get_checkin_data {
|
||||
my ($result) = &query_checkins();
|
||||
|
||||
# we should not depend on any directory being mounted, we are a
|
||||
# deamon.
|
||||
# daemon.
|
||||
|
||||
chdir ("/") ||
|
||||
die("Could not cd to /. $!\n");
|
||||
|
||||
@ -19,8 +19,8 @@
|
||||
# notice board display, build display (colored squares)
|
||||
|
||||
|
||||
# $Revision: 1.19 $
|
||||
# $Date: 2003/06/18 15:47:16 $
|
||||
# $Revision: 1.20 $
|
||||
# $Date: 2003/08/04 17:15:10 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/TinderDB.pm,v $
|
||||
# $Name: $
|
||||
@ -643,8 +643,8 @@ tinderbox server as text files which contain perl code to be
|
||||
evaluated. Each data update is stored in a file with a known name and
|
||||
a unique extension. The tinderbox server is run periodically in
|
||||
daemon_mode and will assimilate all outstanding updates then update
|
||||
the static html files which discribe the state of the build. When
|
||||
tinderbox runs it looks for files with the known prefix then it reads
|
||||
the static html files which describe the state of the build. When
|
||||
tinderbox runs it looks for files with the known prefix than it reads
|
||||
each one in turn, loads it into a common database then deletes the
|
||||
file. To ensure that tinderbox never encounters a partially written
|
||||
file each file is written to the disk using a a name with a different
|
||||
@ -654,7 +654,7 @@ Unix systems, in the same directory, are atomic, tinderbox will never
|
||||
be confused by incomplete updates.
|
||||
|
||||
|
||||
The build module has several lists which the tinder server access via
|
||||
The build module has several lists which the tinder server accesses via
|
||||
known functions. These are used to generate summary data in various
|
||||
formats. (@LATEST_STATUS; @BUILD_NAMES; etc;)
|
||||
|
||||
@ -672,7 +672,7 @@ build data pages using different configuration parameters then is
|
||||
standard.
|
||||
|
||||
The tinderbox server does not use any information about the internal
|
||||
DB format. Each module can use any convienent means to store and
|
||||
DB format. Each module can use any convenient means to store and
|
||||
retrive the required data. Different implementations of the same
|
||||
module may even use different methods of storage. The tinderbox
|
||||
server will ask each module which is implemented to load their
|
||||
@ -692,7 +692,7 @@ for loading and saving databases.
|
||||
|
||||
|
||||
|
||||
Each function discribed here builds an $out string. If there are bugs
|
||||
Each function decribed here builds an $out string. If there are bugs
|
||||
in the resulting HTML you can put your perl breakpoint on the return
|
||||
statement of any function and look at the completed string before it
|
||||
is returned.
|
||||
@ -742,7 +742,7 @@ and will periodically call trim_db_history()
|
||||
=item B<savetree_db>
|
||||
|
||||
Save the current database to disk. This should not be called
|
||||
directly, rather it is called everytime that apply_db_updates() is
|
||||
directly, rather it is called every time that apply_db_updates() is
|
||||
called.
|
||||
|
||||
|
||||
@ -754,8 +754,8 @@ called.
|
||||
|
||||
Purge any history from this trees database which is older then the
|
||||
time given. This should not be called directly, rather it is called
|
||||
everytime the number of updates by apply_db_updates() since the last
|
||||
purge is grater then $MAX_UPDATES_SINCE_TRIM.
|
||||
every time the number of updates made by apply_db_updates() since the
|
||||
last purge is greater then $MAX_UPDATES_SINCE_TRIM.
|
||||
|
||||
|
||||
=back
|
||||
|
||||
@ -1,13 +1,13 @@
|
||||
# -*- Mode: perl; indent-tabs-mode: nil -*-
|
||||
#
|
||||
|
||||
# TinderDB::BT_GENERIC - A generic methods to display the changes to
|
||||
# TinderDB::BT_GENERIC - A generic method to display the changes to
|
||||
# the bug tracking system. I am hoping that we will not need to have
|
||||
# one specialized method per bug ticket system but can instead use
|
||||
# this method for all commonly used (Bug Tracking, Modification
|
||||
# Request) systems. This module will display bugs which have been
|
||||
# 'closed' (developers close bugs when their latest version control
|
||||
# chceck in fixes them) or 'reopened' (since that means that
|
||||
# check in fixes them) or 'reopened' (since that means that
|
||||
# developers closed the bugs incorrectly). BTData.pm contains all the
|
||||
# local settings which configure this module.
|
||||
|
||||
@ -37,8 +37,8 @@
|
||||
# Contributor(s):
|
||||
|
||||
|
||||
# $Revision: 1.21 $
|
||||
# $Date: 2003/05/26 13:41:12 $
|
||||
# $Revision: 1.22 $
|
||||
# $Date: 2003/08/04 17:15:14 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/TinderDB/BT_Generic.pm,v $
|
||||
# $Name: $
|
||||
@ -52,7 +52,7 @@ package TinderDB::BT_Generic;
|
||||
|
||||
# $DATABASE{$tree}{$timenow}{$status}{$bug_id} = $record;
|
||||
|
||||
# Where $rec is an anoymous hash of name vaule pairs from the bug
|
||||
# Where $rec is an anonymous hash of name vaule pairs from the bug
|
||||
# tracking system.
|
||||
|
||||
# we also store information in the metadata structure
|
||||
@ -78,7 +78,7 @@ use VCDisplay;
|
||||
use TinderDB::Notice;
|
||||
|
||||
|
||||
$VERSION = ( qw $Revision: 1.21 $ )[1];
|
||||
$VERSION = ( qw $Revision: 1.22 $ )[1];
|
||||
|
||||
@ISA = qw(TinderDB::BasicTxtDB);
|
||||
|
||||
@ -182,7 +182,7 @@ sub status_table_header {
|
||||
}
|
||||
|
||||
# where can people attach notices to?
|
||||
# Really this is the names the columns produced by this DB
|
||||
# Really this is the names of the columns produced by this DB
|
||||
|
||||
sub notice_association {
|
||||
my ($self, $tree, ) = @_;
|
||||
@ -294,7 +294,7 @@ sub render_bug {
|
||||
|
||||
|
||||
# Return all the bug_ids which changed at any point between the two
|
||||
# row times which represent this cell. Further the data msut be in
|
||||
# row times which represent this cell. Further the data must be in
|
||||
# the column we are currently rendering, that means that the status
|
||||
# must map into the correct column.
|
||||
|
||||
|
||||
@ -3,16 +3,16 @@
|
||||
|
||||
# TinderDB::BT_Req - A modified version of BT_Generic to allow
|
||||
# tinderbox to interface with the Req bug tracking system.
|
||||
# (http://www.draga.com/~jwise/minireq/) eventually the common code
|
||||
# should be factrored out into separate classes but I do not have time
|
||||
# (http://www.draga.com/~jwise/minireq/). Eventually the common code
|
||||
# should be factored out into separate classes but I do not have time
|
||||
# now and the files are only about 400 lines long. The main
|
||||
# difference is that Req requires us to parse a log file for each
|
||||
# tree. Thus we pull the data into our datastructures instead of
|
||||
# having the mail system push it in.
|
||||
|
||||
# The current design of these BT modules does not allow me to have two
|
||||
# copies of the same module (ie two colums both of thehm BT but
|
||||
# configured to use different bug tracking system. This is due to
|
||||
# copies of the same module (ie two colums both of them BT but
|
||||
# configured to use different bug tracking system). This is due to
|
||||
# global variables in the module and the way we configure the system
|
||||
# in TinderConfig and BTData.
|
||||
|
||||
@ -42,8 +42,8 @@
|
||||
|
||||
|
||||
|
||||
# $Revision: 1.5 $
|
||||
# $Date: 2002/05/10 21:18:52 $
|
||||
# $Revision: 1.6 $
|
||||
# $Date: 2003/08/04 17:15:14 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/TinderDB/BT_Req.pm,v $
|
||||
# $Name: $
|
||||
@ -57,7 +57,7 @@ package TinderDB::BT_Req;
|
||||
|
||||
# $DATABASE{$tree}{$timenow}{$status}{$bug_id} = $record;
|
||||
|
||||
# Where $rec is an anoymous hash of name vaule pairs from the bug
|
||||
# Where $rec is an anonymous hash of name vaule pairs from the bug
|
||||
# tracking system.
|
||||
|
||||
# we also store information in the metadata structure
|
||||
@ -82,7 +82,7 @@ use VCDisplay;
|
||||
|
||||
|
||||
|
||||
$VERSION = ( qw $Revision: 1.5 $ )[1];
|
||||
$VERSION = ( qw $Revision: 1.6 $ )[1];
|
||||
|
||||
@ISA = qw(TinderDB::BasicTxtDB);
|
||||
|
||||
|
||||
@ -7,8 +7,8 @@
|
||||
# the build was and display a link to the build log.
|
||||
|
||||
|
||||
# $Revision: 1.63 $
|
||||
# $Date: 2003/08/04 14:32:41 $
|
||||
# $Revision: 1.64 $
|
||||
# $Date: 2003/08/04 17:15:14 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/TinderDB/Build.pm,v $
|
||||
# $Name: $
|
||||
@ -481,7 +481,7 @@ sub loadtree_db {
|
||||
# remove all records from the database which are older then
|
||||
# $TinderDB::TRIM_SECONDS. Since we are making a pass over all
|
||||
# data this is a good time to find the average run time of the build.
|
||||
# Both of these operations need not be run everytime the database is
|
||||
# Both of these operations need not be run every time the database is
|
||||
# updated.
|
||||
|
||||
sub trim_db_history {
|
||||
@ -540,7 +540,7 @@ sub trim_db_history {
|
||||
pop @dead_times;
|
||||
|
||||
# medians are a more robust statistical estimator then the mean.
|
||||
# They will give us better answers then a typical "average"
|
||||
# They will give us better answers than a typical "average"
|
||||
|
||||
delete $DATABASE{$tree}{$buildname}{'average_buildtime'};
|
||||
my $run_avg = main::median(@run_times);
|
||||
@ -576,7 +576,7 @@ sub trim_db_history {
|
||||
|
||||
|
||||
|
||||
# return a list of all the times where an even occured.
|
||||
# return a list of all the times where an event occured.
|
||||
|
||||
sub event_times_vec {
|
||||
my ($self, $start_time, $end_time, $tree) = (@_);
|
||||
@ -685,8 +685,8 @@ sub debug_database {
|
||||
sub status_table_legend {
|
||||
my ($out)='';
|
||||
|
||||
# print user defined legend, this is typicaly all the possible links
|
||||
# which can be included in a build log.
|
||||
# print user defined legend, this is typically all the possible
|
||||
# links which can be included in a build log.
|
||||
|
||||
my $print_legend = BuildStatus::TinderboxPrintLegend();
|
||||
|
||||
@ -803,7 +803,7 @@ sub status_table_header {
|
||||
($IGNORE_BUILDS{$tree}{$buildname}) &&
|
||||
next;
|
||||
|
||||
# create popup text discribing how this build is progressing
|
||||
# create popup text describing how this build is progressing
|
||||
|
||||
my $avg_buildtime = $DATABASE{$tree}{$buildname}{'average_buildtime'};
|
||||
my $avg_deadtime = $DATABASE{$tree}{$buildname}{'average_deadtime'};
|
||||
|
||||
@ -35,8 +35,8 @@
|
||||
# kestes@walrus.com Home.
|
||||
# Contributor(s):
|
||||
|
||||
# $Revision: 1.33 $
|
||||
# $Date: 2003/06/18 15:48:26 $
|
||||
# $Revision: 1.34 $
|
||||
# $Date: 2003/08/04 17:15:15 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/TinderDB/VC_CVS.pm,v $
|
||||
# $Name: $
|
||||
@ -139,7 +139,7 @@ use TreeData;
|
||||
use VCDisplay;
|
||||
|
||||
|
||||
$VERSION = ( qw $Revision: 1.33 $ )[1];
|
||||
$VERSION = ( qw $Revision: 1.34 $ )[1];
|
||||
|
||||
@ISA = qw(TinderDB::BasicTxtDB);
|
||||
|
||||
@ -766,7 +766,7 @@ sub status_table_row {
|
||||
$text_browser_color_string =
|
||||
HTMLPopUp::text_browser_color_string($cell_color, $char);
|
||||
|
||||
# for those who like empty cells to be truely empty, we need to
|
||||
# for those who like empty cells to be truly empty, we need to
|
||||
# be sure that they see the different cell colors when they
|
||||
# change.
|
||||
|
||||
|
||||
@ -77,8 +77,8 @@
|
||||
# Contributor(s):
|
||||
|
||||
|
||||
# $Revision: 1.17 $
|
||||
# $Date: 2003/08/04 14:32:41 $
|
||||
# $Revision: 1.18 $
|
||||
# $Date: 2003/08/04 17:15:15 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/TinderDB/VC_Perforce.pm,v $
|
||||
# $Name: $
|
||||
@ -158,7 +158,7 @@ use Utils;
|
||||
use VCDisplay;
|
||||
|
||||
|
||||
$VERSION = ( qw $Revision: 1.17 $ )[1];
|
||||
$VERSION = ( qw $Revision: 1.18 $ )[1];
|
||||
|
||||
@ISA = qw(TinderDB::BasicTxtDB);
|
||||
|
||||
@ -532,7 +532,7 @@ sub status_table_row {
|
||||
$text_browser_color_string =
|
||||
HTMLPopUp::text_browser_color_string($cell_color, $char);
|
||||
|
||||
# for those who like empty cells to be truely empty, we need to
|
||||
# for those who like empty cells to be truly empty, we need to
|
||||
# be sure that they see the different cell colors when they
|
||||
# change.
|
||||
|
||||
|
||||
@ -8,8 +8,8 @@
|
||||
# TreeState, Build, IgnoreBuilds, MOTD, Images,
|
||||
|
||||
|
||||
# $Revision: 1.8 $
|
||||
# $Date: 2002/04/27 04:11:33 $
|
||||
# $Revision: 1.9 $
|
||||
# $Date: 2003/08/04 17:15:10 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/TinderHeader.pm,v $
|
||||
# $Name: $
|
||||
@ -431,7 +431,7 @@ If some headers are not desired to run the 'use' statements for them
|
||||
may be safely commented out and a default value will automatically be
|
||||
provided.
|
||||
|
||||
Each function discribed here builds an $out string. If there are bugs
|
||||
Each function described here builds an $out string. If there are bugs
|
||||
in the resulting HTML you can put your perl breakpoint on the return
|
||||
statement of any function and look at the completed string before it
|
||||
is returned.
|
||||
|
||||
@ -3,8 +3,8 @@
|
||||
# Utils.pm - General purpose utility functions. Every project needs a
|
||||
# kludge bucket for common access.
|
||||
|
||||
# $Revision: 1.36 $
|
||||
# $Date: 2003/05/26 13:30:43 $
|
||||
# $Revision: 1.37 $
|
||||
# $Date: 2003/08/04 17:15:11 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/Utils.pm,v $
|
||||
# $Name: $
|
||||
@ -207,14 +207,14 @@ sub get_env {
|
||||
|
||||
sub chk_security {
|
||||
|
||||
# look at several potential security problems and die if they
|
||||
# could cause us problems.
|
||||
# Look at several potential security problems and die if they
|
||||
# could cause us problems.
|
||||
|
||||
# Check effective uid of the process to see if we have
|
||||
# Check effective uid of the process to see if we have
|
||||
# been configured to run with too much privileges.
|
||||
|
||||
# Ideally we do not want the tinderbox application running with the
|
||||
# priveledges of a restricted user id (like: root, daemon, bin,
|
||||
# privileges of a restricted user id (like: root, daemon, bin,
|
||||
# mail, adm) this should not happen because users configure it
|
||||
# (dangerous) or because of some security accident.
|
||||
|
||||
@ -224,13 +224,13 @@ sub chk_security {
|
||||
( $> == $tinderbox_uid ) ||
|
||||
die("Security Error. ".
|
||||
"Must not run this program using an effective user id ".
|
||||
"which is different then the tinderbox user id. ".
|
||||
"which is different than the tinderbox user id. ".
|
||||
"id: $> id must be $tinderbox_uid\n");
|
||||
|
||||
( $) == $tinderbox_gid) ||
|
||||
die("Security Error. ".
|
||||
"Must not run this program using effective group id ".
|
||||
"different then tinderbox group id.".
|
||||
"different than tinderbox group id.".
|
||||
"id: $) must be $tinderbox_gid\n");
|
||||
|
||||
|
||||
@ -445,8 +445,8 @@ sub fatal_error {
|
||||
}
|
||||
print LOG "\n";
|
||||
|
||||
# do not check for errors, the lock file may not exits and even if
|
||||
# we have trouble removing the file we we will be exiting anyway.
|
||||
# Do not check for errors, the lock file may not exist and even if
|
||||
# we have trouble removing the file we will be exiting anyway.
|
||||
|
||||
unlink ($LOCK_FILE);
|
||||
|
||||
@ -514,7 +514,7 @@ sub overwrite_file {
|
||||
my ($dirname) = File::Basename::dirname($outfile);
|
||||
my ($basename) = File::Basename::basename($outfile);
|
||||
|
||||
# It is important that the tmp files have a Unique prefix so that #
|
||||
# It is important that the tmp files have a Unique prefix so that
|
||||
# when the TinderDB globs for update files it does not find the half
|
||||
# written updates.
|
||||
|
||||
@ -592,7 +592,7 @@ sub require_modules {
|
||||
|
||||
foreach $impl (@impls) {
|
||||
|
||||
# '$impl' is not a bare word so we must preform this data
|
||||
# '$impl' is not a bare word so we must perform this data
|
||||
# transformation which require normally does
|
||||
|
||||
$impl =~ s!::!/!g;
|
||||
@ -669,7 +669,7 @@ sub fix_time_format {
|
||||
# ----------
|
||||
|
||||
# The 'extract' functions will untaint their input data and return
|
||||
# only data which meets the extraction critireion.
|
||||
# only data which meets the extraction criterion.
|
||||
|
||||
# ----------
|
||||
|
||||
|
||||
@ -4,8 +4,8 @@
|
||||
# installed bonsai and are using cvsblame cvsguess and cvsquery to let
|
||||
# your webserver render html pages of your CVS repository.
|
||||
|
||||
# $Revision: 1.10 $
|
||||
# $Date: 2003/02/11 00:16:34 $
|
||||
# $Revision: 1.11 $
|
||||
# $Date: 2003/08/04 17:15:17 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/hwine/cvs_conversion/cvsroot/mozilla/webtools/tinderbox2/src/lib/VCDisplay/Bonsai.pm,v $
|
||||
# $Name: $
|
||||
@ -85,7 +85,7 @@ $CVSGUESS = $BONSAI_URL."/cvsguess.cgi";
|
||||
|
||||
# Bonsai wants the CVS root to be a local root. i.e. use '/cvsroot'
|
||||
# not ':pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot'. Sometimes
|
||||
# it is convienent to keep the remote server information in the
|
||||
# it is convenient to keep the remote server information in the
|
||||
# tinderbox config so that we can run BOTH the CVS and Bosai TinderDB
|
||||
# modules at the same time.
|
||||
|
||||
@ -167,10 +167,10 @@ sub prepare_bonsai_args {
|
||||
"maxdate: $args{'maxdate'}: ".time2bonsai($args{'maxdate'})."\n".
|
||||
""));
|
||||
|
||||
# Convert times to a human readable date for the convience of the
|
||||
# users. Bonsai excepts data of form: 'mm/dd/yyyy hh:mm:ss' in
|
||||
# addition to time format.
|
||||
|
||||
# Convert times to a human readable date for the convenience of
|
||||
# the users. Bonsai excepts data of form: 'mm/dd/yyyy hh:mm:ss'
|
||||
# in addition to time format.
|
||||
|
||||
($args{'mindate'}) &&
|
||||
(push @url_args, "mindate=".time2bonsai($args{'mindate'}) );
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user