As of November 2016, Microsoft Windows Updates are now available for download from the Microsoft Update Catalog only. As always, all updates will still be available via WSUS, SCCM, and Windows Update – this change is only for manual downloads. Install this update to resolve issues in Windows. Collaborator is a code review tool that helps development, testing and management teams work together to produce high quality code. It allows teams to peer review code, user stories and test plans in a transparent, collaborative framework — instantly keeping the entire team up to speed on changes made to the code.
This section is concerned with unpacking the Codestriker distribution into a suitable location, and then configuring it. For UNIX distribution, the following commands may be appropriate on your system:% mkdir /var/www/codestriker% cd /var/www/codestriker% tar zxvf /from/installed/location/codestriker-X.Y.Z.tar.gz% chown -R apache.apache /var/www/codestriker/codestriker-X.Y.Z Here 'apache' is the user which runs the Apache server. It could be 'nobody' under different systems. Check with the ps auxww command, or check your Apache configuration files.
Under Windows, the Codestriker distribution could be unzipped into a suitable location under c: program files, or just c: codestriker. The next task is to edit the codestriker.conf configuration file to reflect the settings on your site. The file is documented with examples to assist in setting appropriate values. The file is in Perl syntax, so lines starting with a '#' indicate a comment. The $db variable should be set to a DBI URL representing the Codestriker database that was created, as specified in. Basically, if you are using PostgreSQL, this should be: $db = 'DBI:Pg:dbname=codestrikerdb'; For MySQL, this would be: $db = 'DBI:mysql:dbname=codestrikerdb'; If your database is situated on a different host, for example 'dbhost', this could be modified to: $db = 'DBI:mysql:dbname=codestrikerdb;host=dbhost'; In this situation, you need to ensure that the webserver host has permission to connect to the database on dbhost. Check the MySQL documentation for further details.
The database user and password also need to be specified. If your username was 'codestriker', and the password was 'cspasswd', the settings would be just: # Database user. $dbuser = 'codestriker'; # Database password. $dbpasswd = 'cspasswd'; Other examples for other database systems are present in the configuration file. When a code review topic is created, or a comment against a review is made, an email is sent out as a notification mechanism. Codestriker needs to know what mail host it can use for sending email messages. The configuration file default is 'localhost': # Location of the mailing host.
This is used when sending out codestriker # comments. $mailhost = 'localhost'; If your mail server requires SMTP authentication for sending emails, the username and password can be set via the $mailuser and $mailpasswd parameters. # Set the user and password parameters if $mailhost requires SMTP # authentication. If commented out, it is assumed authentication is # not required.
$mailuser = 'smtpuser'; $mailpasswd = 'smtppasswd'; If these values are commented out, it is assumed SMTP authentication is not required. Some of the HTML pages generated by Codestriker can be quite large, depending on the review size. If your deployment is operating to users outside an intranet, it may be worth enabling this option to enable compression. Note, IE doesn't support receiving compressed HTML, so setting this option will have no effect. Initially, it is best to leave this option turned off (the default), and only to enable it if there is a significant performance problem. # Indicate whether to try and compress output if the client browser # supports it.
This can make a tremendous difference in bandwidth, # especially over slow links. $usecompression = 0. It is often useful to link the creation of code review topics with the associated bug records that the code is fixing.
That way, it is possible to read a bug record, and apart from reading the textual description as to how it has been resolved, Codestriker can add in a link to the code review topic, which shows the actual code which fixed the bug (and any important decisions made in the Codestriker comments). Currently, there is support for Bugzilla, Flyspray Mantis and TestDirector, but it is not difficult to add in support for other systems. If you don't use a bugtracker you can skip this section, as by default, there is no linking to a bug tracking system. An example configuration could be as follows: # Bug tracking type.
$bugdb = 'bugzilla'; # Bug database connection details. $bugdbhost = 'localhost'; $bugdbname = 'bugs'; $bugdbpassword = 'bugspassword'; $bugdbdbname = 'bugs'; # Bugzilla codestriker user id. $bugdbuserid = '2'; The $bugdb setting indicates to use Bugzilla.
If this value is set to ', then no linkage to a bug tracking system is performed (the default). The $bugdbhost setting indicates the hostname that holds the bugzilla database, while $bugdbname and $bugdbpassword contain the database username and password to connect to the Bugzilla database. The $bugdbdbname setting contains the Bugzilla database name, which by default is 'bugs'.
![Install Install](/uploads/1/2/3/7/123763425/806591017.png)
You can verify these settings by using mysql to connect to the Bugzilla database interactively. Codestriker adds 'comments' to the appropriate bug record whenever a code review topic has been created against it, or the review's state has changed. To do this, a special Bugzilla user needs to be created which the comments will be created against. Create the user using the Bugzilla interface, and call it '[email protected]'. Then connect to the Bugzilla database using mysql, and execute the following command to determine the userid of the user just created: SELECT userid FROM profiles WHERE loginname = '[email protected]'; This value should be set into the $bugdbuserid setting. # Bugzilla codestriker user id.
$bugdbuserid = '2'. Codestriker stores the topic text, description and comments as UTF-8. When creating a topic, Codestriker needs to be told what encoding your files are stored in.
By default, Codestriker assumes it is UTF-8 (compatible with ASCII). If your source code files are stored in another encoding (for example, gb2312 for a Chinese team), this needs to be specified in the $topictextencoding variable. # Character encoding to use when reading topic text. Default is utf8 # (compatible with ASCII) if not set, but this can be over-ridden here.
# List of example encoding names can be retrieved from the following # URL: #$topictextencoding = 'utf8'; #$topictextencoding = 'gb2312'. There are a number of other options which affect how Codestriker runs. The most important ones are shown below. Unless you have specific reasons to, most intranet deployments of Codestriker can leave these options as is.
# Exclude these file types from review topics. # You will generally want to exclude any non-human-readable files. @excludefiletypes = ('rtf', 'doc', 'gif', 'bmp', 'jpeg', 'jpg', 'mdb', 'ppt', 'vsd', 'xls', 'zip', 'tgz', 'tar', 'gz', 'opt', 'aps', 'ncb', 'a', 'so', 'dll', 'lib', 'exe', 'png', 'pdf', 'bin', 'out', 'ld', 'fm', 'indd', 'wav', 'o', 'obj', 'mpp', 'vsw', 'jfif', 'tif', 'tiff', 'xbm', 'fnt', 'ttf', 'pfm', 'pfb', 'eps', 'wpj', 'sxi'); # Indicate if topics can be listed/searched. Turning this to false can be # useful for 'anonymous' installations of Codestriker. $allowsearchlist = 1; # Indicate if the repository attribute can be set to a topic. If this # is disabled, it won't be possible to view the entire contents of a # file before the proposed change and/or after.
On some servers (such # as sourceforge), the firewall doesn't allow CGI scripts to make # remote connections. $allowrepositories = 1; # The following controls project configuration. Each Codestriker topic is # a member of a specific project. Uncomment the option you want # below. Note the textual state names below cannot be changed.
# Default option, projects are enabled, but they have no state # changing operations (ie, projects are always in state 'Open'). @projectstates = ('Open'); # Don't use projects at all. Effectively, an implicit 'default # project' is created and associated with all topics behind the scenes.
# @projectstates = ; # # Allow for projects to be closed. Closing a project will # not allow new topics to be created in that project. # @projectstates = ('Open', 'Closed'); # # Allow for projects to be deleted.
This is potentially a dangerous # option to allow, as deleting a project will delete all of its member # topics as well. Use with caution. # @projectstates = ('Open', 'Deleted'); # # Allow for projects to be closed and deleted.
Use with caution. # @projectstates = ('Open', 'Closed', 'Deleted'); # If true, don't display any email addresses in their true form, but # truncate them, to beat SPAM harvesters.
$antispamemail = 0. As explained by the comments in the configuration file, it is possible to limit the size of code review topics that will be accepted by the system: # The number of problems found per line drops if the size of the # topic is too large. A common inspection pitfall is for authors to # attempt to review too much material and then miss problems. # These two options allow the Codestriker administrator to limit # the length of the topics. Topics that have more lines than # $maximumtopicsizelines are rejected when they are created. # Topics that are larger than $suggestedtopicsizelines generate # a warning displayed in the topic page, but are accepted into the # system. Codestriker measures that length of the topic by counting # the number of lines in the topic text.
# # The Codestriker default of not enforcing any limits is specified by # settings either option to an empty string. If you are not sure # what a reasonable limit would be, start with a suggestedtopicsizelines # set to 350, and adjust with experience. $maximumtopicsizelines = '; $suggestedtopicsizelines = '. By default, whenever a comment it submitted, an email will be sent to the author of the comment, the author of the review, and anyone else who has submitted a comment on the line of code in question. This may not be appropriate for some team processes, and can be changed by setting $allowcommentemail to 0.
# If true, Codestriker will send out emails to the topic owner and # comment submitter when a comment is added. If this option is false, # no email will be sent to either the topic owner or the comment # submitter.
Emails about each comment may not be needed if a meeting # is planned to discuss the topic. If the comment submitter specifies # a cc user, an email is always sent out, regardless of this setting.
$allowcommentemail = 1. As explained by the comments in the configuration file, it it possible to specify by default, whether topics display the deltas for all files in the review, or just a single file at a time by default. The viewing mode can be changed dynamically on the view topic screen. # When displaying a topic, if this value is -1, then all files in the # topic are displayed in the one page (default old Codestriker # behaviour). If the value is 0, then only the first file is shown, # with links to display the other files.
This is useful for those # deployments that review a large amount of code. $defaultfiletoview = -1.
As explained by the comments in the configuration file, it is possible to maintain software metrics obtained from the code reviewing process. There is also scope for customising Codestriker to track your own software metrics. # This options configures the metric support in codestriker. You have # the following options: # # $metricconfig = 'none', 'basic', 'all', 'metric name, metric name, etc' # # 'none' - turns off all extra metric support in the application.
The # metric page will only display and manage data that is strictly # required to perform the review. Codestriker will not require any # addition data input from the reviewers and authors. This is the # default. However, you still get basic data like how many topics are # being created and how problems are being found. # # 'basic' - Turns on the metrics that are considered to be essential # for a metric program. It will require that reviewers and authors # enter the time spent reviewing the topic, the time spent in the # review meeting, and the time spent preparing for the review. The # metric selection assumes that you are following a formal review # process with a preparation meeting, and a defect review meeting.
# # kickoff time - time spent preparing for the review # checking time - time spent actually reviewing the topic. # logging meeting duration - the time spent in the logging meeting. # # 'all' - Turns on all of the metrics that one could possibly want to # track. The list of metrics is from the book 'Software Inspection' by # Gilb and Graham. You should probably not use this unless you are # using a formal process that is well established. You may want to # enable this temporally to get a idea of the types of metrics that # are supported.
# # 'name,name' - Lastly, you can pick and chose what metrics you would # like to enable. Just list the metric names in a comma separated # list.
You can see all of the build in metrics in the # lib/Codestriker.pm file. For example, if you don't hold a kick off # meeting, and but do hold a logging meeting, the basic option will not # quit fit.
You should set the $metricconfig as: # $metricconfig = 'checking time,logging meeting duration'. # # If you don't like our choices of metrics, the names, descriptions, # etc feel free to edit the lib/Codestriker.pm.
It contains # documentations on how to add your own metrics into codestriker. It # is easy to do, and does not require any coding. $metricconfig = 'none'. It is possible for Codestriker to integrate with ScmBug. This allows users to generate a topic based on the changes done under a given bug ID (or list of bug IDs). An example configuration is: $scmbughostname = 'localhost'; $scmbugport = 3872; $scmbuglibdir = 'C:/Program Files/Scmbug/share/scmbug/lib'; This would match the default settings used by Scmbug on Windows. Where $scmbughostname and $scmbugport are the host and port of the machine where Scmbug is running.
The $scmbuglibdir points to the lib directory under the Scmbug installation. If Scmbug is running on a separate machine a copy of the Scmbug lib directory needs to be staged on the same machine as codestriker and the $scmbuglibdir variable made to point at this. Using ScmBug for creating topics can generate a very large number of requests to your SCM system.
If your SCM system is running under a Unix system, you might need to increase the number of allowed requests per-minute in your inetd configuration, otherwise you might experience hangs while creating ScmBug topics.