зеркало из https://github.com/mozilla/pjs.git
more spelling fixes from the master "Olly Betts" <olly@survex.com>
This commit is contained in:
kestes%walrus.com
Родитель
202b41314d
Коммит
403d54f9f1
|
|
@ -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 'priviledged id's from running Tinderbox.
|
||||
No longer exclude 'privileged id's from running Tinderbox.
|
||||
Now we require tinderbox to run as the id which the user specifies
|
||||
is the tinderbox id.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
data strucutres are easy to read and debug. Currently this is a
|
||||
data structures 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
|
||||
|
|
|
|||
|
|
@ -40,9 +40,9 @@ difference the two. As an example you might need to change the
|
|||
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
|
||||
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 laied
|
||||
may have unusual requirements for how the filesystem should be laid
|
||||
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
|
||||
|
|
|
|||
|
|
@ -3,11 +3,11 @@
|
|||
#
|
||||
|
||||
# addnote.cgi - the webform via which users enter notices to be
|
||||
# on the tinderbox status page.
|
||||
# displayed on the tinderbox status page.
|
||||
|
||||
|
||||
# $Revision: 1.22 $
|
||||
# $Date: 2003-08-04 17:14:56 $
|
||||
# $Revision: 1.23 $
|
||||
# $Date: 2003-08-16 18:31:03 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/bin/addnote.cgi,v $
|
||||
# $Name: $
|
||||
|
|
|
|||
|
|
@ -12,8 +12,8 @@
|
|||
# server. No locks are used by the mail processes, data is passed to
|
||||
# the tinderbox server in a maildir like format.
|
||||
|
||||
# $Revision: 1.32 $
|
||||
# $Date: 2003-08-04 17:14:58 $
|
||||
# $Revision: 1.33 $
|
||||
# $Date: 2003-08-16 18:31:03 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/bin/processmail_builds,v $
|
||||
# $Name: $
|
||||
|
|
@ -117,7 +117,7 @@ Mail is expected to consist of
|
|||
2) The build/test log as output by the tool which was run to
|
||||
generate the build.
|
||||
|
||||
3) The binary which results form the build, if desired.
|
||||
3) The binary which results from the build, if desired.
|
||||
|
||||
Mail messages are parsed to extract the tinderbox variables and
|
||||
database update files are written for the tinderbox server to pickup
|
||||
|
|
@ -131,27 +131,27 @@ 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 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
|
||||
information is passed in the database update files. There may be
|
||||
serveral instances of this program running so each database update
|
||||
file is written to the disk with a unique name. No locks are held by
|
||||
this code.
|
||||
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
|
||||
started 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 information is passed in the database update files.
|
||||
There may be serveral instances of this program running so each
|
||||
database update 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 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
|
||||
the log file and get a feel for how far into the compilation the build
|
||||
machine has progressed.
|
||||
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 the log file and get a feel for how far into the
|
||||
compilation the build machine has progressed.
|
||||
|
||||
|
||||
Mail Format
|
||||
|
||||
The mail has a very simple format and is not MIME encoded and has not
|
||||
The mail has a very simple format and is not MIME encoded and has no
|
||||
attachments.
|
||||
|
||||
The tinderbox variables must be at the top of the mail and the last
|
||||
|
|
@ -397,7 +397,7 @@ sub set_filenames {
|
|||
|
||||
|
||||
# If the field is a date prefer the output of fix_time_format to what
|
||||
# is passed into the program. We may recieve human readable strings
|
||||
# is passed into the program. We may receive human readable strings
|
||||
# and these need to be converted to time() format.
|
||||
|
||||
|
||||
|
|
@ -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 greater then min time between builds.
|
||||
2) has a starttime greater than 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 libraraies are messy since they cause variable run
|
||||
# autoload for libraries are messy since they cause variable run
|
||||
# time requirements.
|
||||
|
||||
$TINDERBOX{'timenow'} = main::extract_digits($TINDERBOX{'timenow'});
|
||||
|
|
@ -843,7 +843,7 @@ sub parse_mail_body {
|
|||
|
||||
# it is a bug in processing should this function be called before
|
||||
# the tinderbox variables are set. We intentionally leave off the \n
|
||||
# on some of thed die's to get tracebacks of internal errors.
|
||||
# on some of the die's to get tracebacks of internal errors.
|
||||
|
||||
# We must use HTMLPopUp::escapeHTML to clean up any embedded HTML in the
|
||||
# mail messege to prevent attacks. Though it may be more friendly
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
# -*- Mode: perl; indent-tabs-mode: nil -*-
|
||||
#
|
||||
|
||||
# $Revision: 1.33 $
|
||||
# $Date: 2003-08-04 17:14:59 $
|
||||
# $Revision: 1.34 $
|
||||
# $Date: 2003-08-16 18:31:03 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/bin/tinder.cgi,v $
|
||||
# $Name: $
|
||||
|
|
@ -133,10 +133,11 @@ 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 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.
|
||||
New data is pushed into the system via administrative web forms and
|
||||
via mail which is delivered to the helper program processmail and has
|
||||
the specified format. Additional data is gathered by having the
|
||||
program query the Version Control Software to find any updates which
|
||||
have happended recently.
|
||||
|
||||
Errors are logged to the logfile: $ERROR_LOG
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
# This script does not need to run under taint perl.
|
||||
|
||||
# A generic build script for tinderbox. This script will run any
|
||||
# sequence of shell command for building or testing an application.
|
||||
# sequence of shell commands for building or testing an application.
|
||||
# Users create a configuration file which defines the steps needed to
|
||||
# build, the build environmental variables and other information which
|
||||
# tinderbox will need.
|
||||
|
|
@ -32,8 +32,8 @@
|
|||
# complete rewrite by Ken Estes, Mail.com (kestes@staff.mail.com).
|
||||
# Contributor(s):
|
||||
|
||||
# $Revision: 1.15 $
|
||||
# $Date: 2003-08-04 17:15:02 $
|
||||
# $Revision: 1.16 $
|
||||
# $Date: 2003-08-16 18:31:05 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Name: $
|
||||
|
||||
|
|
@ -131,7 +131,7 @@ 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. 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
|
||||
should be performed inside developer maintained scripts (shell, perl,
|
||||
Makefile).
|
||||
|
||||
Different sequences of build instructions have different 'build
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
# especially if you are running builds on many different OS and platforms
|
||||
# which require different command sequences. Each build type
|
||||
# (construct, test, lint) defines a sequence of commands which is the
|
||||
# same on all build machines. They types each have different commands
|
||||
# same on all build machines. The types each have different commands
|
||||
# to run but the commands are simple because all the difficult work is
|
||||
# performed inside makefiles and shell scripts. There is one parser
|
||||
# on the tinderbox server for each type of build. This cf file will
|
||||
|
|
@ -24,8 +24,8 @@
|
|||
# variables substituted.
|
||||
|
||||
|
||||
# $Revision: 1.8 $
|
||||
# $Date: 2003-08-04 17:15:02 $
|
||||
# $Revision: 1.9 $
|
||||
# $Date: 2003-08-16 18:31:05 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/clientbin/generic.sample.buildcf,v $
|
||||
# $Name: $
|
||||
|
|
@ -196,7 +196,7 @@ sub build_scripts {
|
|||
}
|
||||
|
||||
# pass these variables to the Makefile.orig so that the
|
||||
# buildid can contain this information.
|
||||
# build id can contain this information.
|
||||
|
||||
$ENV{'BUILD_CVS_D_TIME'} = $filename_time_str;
|
||||
$ENV{'BUILD_BRANCH'} = $branch;
|
||||
|
|
@ -397,7 +397,7 @@ sub mail_from {
|
|||
|
||||
|
||||
# Tell the tinderbox webserver what page to display the build
|
||||
# information. In our case we use the same build instructions for
|
||||
# information on. In our case we use the same build instructions for
|
||||
# several different products so this information must be passed in on
|
||||
# the command line. We must have this information or the build can
|
||||
# not be displayed on the webserver, so it is a fatal error not to
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@
|
|||
# substituted.
|
||||
|
||||
|
||||
# $Revision: 1.4 $
|
||||
# $Date: 2003-08-04 17:15:02 $
|
||||
# $Revision: 1.5 $
|
||||
# $Date: 2003-08-16 18:31:05 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/clientbin/mozilla.unix.buildcf,v $
|
||||
# $Name: $
|
||||
|
|
@ -302,12 +302,12 @@ sub build_scripts {
|
|||
|
||||
# Each phase must have the following entries:
|
||||
|
||||
# phase_name: discribes what the phase is.
|
||||
# phase_name: describes 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 exected in order
|
||||
# script: a list of shell commands to be executed 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
|
||||
|
|
|
|||
|
|
@ -19,8 +19,8 @@
|
|||
# notice board display, build display (colored squares)
|
||||
|
||||
|
||||
# $Revision: 1.20 $
|
||||
# $Date: 2003-08-04 17:15:10 $
|
||||
# $Revision: 1.21 $
|
||||
# $Date: 2003-08-16 18:31:07 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/lib/TinderDB.pm,v $
|
||||
# $Name: $
|
||||
|
|
@ -644,7 +644,7 @@ 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 describe the state of the build. When
|
||||
tinderbox runs it looks for files with the known prefix than it reads
|
||||
tinderbox runs it looks for files with the known prefix then 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
|
||||
|
|
@ -692,7 +692,7 @@ for loading and saving databases.
|
|||
|
||||
|
||||
|
||||
Each function decribed 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.
|
||||
|
|
@ -776,7 +776,7 @@ implementation puts into the build table.
|
|||
|
||||
=item B<status_table_header>
|
||||
|
||||
return a header line appropriate for theset of columns this
|
||||
return a header line appropriate for the set of columns this
|
||||
implementation puts into the build table.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@
|
|||
# Contributor(s):
|
||||
|
||||
|
||||
# $Revision: 1.22 $
|
||||
# $Date: 2003-08-04 17:15:14 $
|
||||
# $Revision: 1.23 $
|
||||
# $Date: 2003-08-16 18:31:09 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/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 anonymous hash of name vaule pairs from the bug
|
||||
# Where $rec is an anonymous hash of name value 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.22 $ )[1];
|
||||
$VERSION = ( qw $Revision: 1.23 $ )[1];
|
||||
|
||||
@ISA = qw(TinderDB::BasicTxtDB);
|
||||
|
||||
|
|
|
|||
|
|
@ -42,8 +42,8 @@
|
|||
|
||||
|
||||
|
||||
# $Revision: 1.6 $
|
||||
# $Date: 2003-08-04 17:15:14 $
|
||||
# $Revision: 1.7 $
|
||||
# $Date: 2003-08-16 18:31:09 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/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 anonymous hash of name vaule pairs from the bug
|
||||
# Where $rec is an anonymous hash of name value pairs from the bug
|
||||
# tracking system.
|
||||
|
||||
# we also store information in the metadata structure
|
||||
|
|
@ -82,7 +82,7 @@ use VCDisplay;
|
|||
|
||||
|
||||
|
||||
$VERSION = ( qw $Revision: 1.6 $ )[1];
|
||||
$VERSION = ( qw $Revision: 1.7 $ )[1];
|
||||
|
||||
@ISA = qw(TinderDB::BasicTxtDB);
|
||||
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@
|
|||
# the build was and display a link to the build log.
|
||||
|
||||
|
||||
# $Revision: 1.64 $
|
||||
# $Date: 2003-08-04 17:15:14 $
|
||||
# $Revision: 1.65 $
|
||||
# $Date: 2003-08-16 18:31:09 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/lib/TinderDB/Build.pm,v $
|
||||
# $Name: $
|
||||
|
|
@ -685,7 +685,7 @@ sub debug_database {
|
|||
sub status_table_legend {
|
||||
my ($out)='';
|
||||
|
||||
# print user defined legend, this is typically all the possible
|
||||
# Print user defined legend, this is typically all the possible
|
||||
# links which can be included in a build log.
|
||||
|
||||
my $print_legend = BuildStatus::TinderboxPrintLegend();
|
||||
|
|
@ -1315,7 +1315,7 @@ sub buildcell_links {
|
|||
|
||||
# Binary file Link
|
||||
my $binary_ref = (
|
||||
FileStructure::get_filename($tree, build_din_dir) .
|
||||
FileStructure::get_filename($tree, build_bin_dir) .
|
||||
$current_rec->{'binaryname'}
|
||||
);
|
||||
|
||||
|
|
|
|||
|
|
@ -3,8 +3,8 @@
|
|||
# Utils.pm - General purpose utility functions. Every project needs a
|
||||
# kludge bucket for common access.
|
||||
|
||||
# $Revision: 1.37 $
|
||||
# $Date: 2003-08-04 17:15:11 $
|
||||
# $Revision: 1.38 $
|
||||
# $Date: 2003-08-16 18:31:07 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/jrmuizel/cvs-mirror/mozilla/webtools/tinderbox2/src/lib/Utils.pm,v $
|
||||
# $Name: $
|
||||
|
|
@ -211,7 +211,7 @@ sub chk_security {
|
|||
# could cause us problems.
|
||||
|
||||
# Check effective uid of the process to see if we have
|
||||
# been configured to run with too much privileges.
|
||||
# been configured to run with too many privileges.
|
||||
|
||||
# Ideally we do not want the tinderbox application running with the
|
||||
# privileges of a restricted user id (like: root, daemon, bin,
|
||||
|
|
@ -230,7 +230,7 @@ sub chk_security {
|
|||
( $) == $tinderbox_gid) ||
|
||||
die("Security Error. ".
|
||||
"Must not run this program using effective group id ".
|
||||
"different than tinderbox group id.".
|
||||
"different than the tinderbox group id.".
|
||||
"id: $) must be $tinderbox_gid\n");
|
||||
|
||||
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче