An email can be sent when an integration activity, either commiting or labeling, is accepted. This is defined in the glue configuration file using the mail_on_success policy variable, as shown in Figure 4-23. Emails can also be sent after a failed commit activity if the SCM system overshadows and does not report the error message using the mail_on_failure policy variable.
![]() | For example, Subversion does not report error messages of its post-commit hook. |
Figure 4-23. Mail notification policy.
# # Send email notifications after integration activity # mail_notification => { # Send an email after a successful activity (both # verifying and labeling) mail_on_success => 0, # Send an email after a failed commit activity that the # SCM system may overshadow and not report # (e.g. Subversion does not report error messages of its # post-commit hook.) . mail_on_failure => 1, mail_settings => { # Must be a valid email address. Can remain empty if # other users should be notified. To => 'replace_with_commit_mailing_list_email@exampledomain.com', # Must be a valid email address. Can remain empty if # mail_also_appears_from_scm_user is enabled. From => 'Scmbug <replace_with_mailing_list_owner_email@exampledomain.com>', # Defaults to localhost if left empty Smtp => 'replace_with_mail_server.exampledomain.com' }, # Sending email when a tag is moved or deleted in CVS can # be annoying, since multiple emails are sent per # directory (but not when a tag is added). mail_on_label # can disable that behavior. mail_on_label => 1, mail_recipients => { # Make the email also appear to have been sent by the # SCM user. mail_also_appears_from_scm_user => 1, # List of users that will be notified mail_scm_user => 1, mail_bug_owner => 1, mail_bug_reporter => 1, mail_bug_monitors => 1, mail_product_owners => 1 } }
It is possible to automatically change the resolution status of a bug at the time a software change is committed. It is verified that the requested resolution status is a valid resolution state in the bug-tracker and that the requested change does not violate the workflow of the bug-tracker. For example, changing a bug resolution in Bugzilla from REOPENED to UNCONFIRMED is an invalid status change.
Changing resolution status is accomplished if a resolution template expected by Scmbug is identified in the log message. The resolution does not need to apply to the same bug the software change is applied against. It could be applied to a different bug, multiple bugs, or multiple different resolutions could be applied to multiple different bugs. The resolution template must be specified on a separate line on its own and is completely removed before the log message is identified.
Four regular expressions describe how the bug id, the new status, the status resolution, and the status resolution data will be identified. These are defined as part of the resolution_template policy variable as shown in Figure 4-24, through the variables resolution_bugid_regex, resolution_status_regex, resolution_status_resolution_regex, and resolution_status_resolution_data_regex.
A way to split a list of multiple bug ids into separate ids is also described with a regular expression through the variable resolution_bugid_split_regex. An example log message accepted by these expressions is shown in Figure 4-26.
Figure 4-24. Regular expressions describing the bug id, the split of bug ids and the resolution status.
# Resolution template. # # Regular expressions that describe how a resolution status # for a list of bug ids can be identified resolution_template => { enabled => 1, # The resolution_bugid_regex is a regular expression that # must set the unnamed variable $1 to the bug number, or # list of bug numbers. It is checked for a match as: # m/$regex/s resolution_bugid_regex => '^\s*status\s*([\d|\s|,|#]*?):', # The resolution_bugid_split_regex is a regular expression # describing how a list of bug ids will be split in # individual bug numbers. It is split as: /$regex/ resolution_bugid_split_regex => ',\s?#|\s?#|,|\s+', # The resolution_status_regex is a regular expression that # must set the unnamed variable $1 to the requested # status. It is checked for a match as: m/$regex/s # # For example, if one issued in the log message the # resolution command: # # status 547: reopened # # Then the resolution_status_regex is expected to match # "reopened" resolution_status_regex => '^\s*status.*?:\s*(\S+)\s*.*', # The resolution_status_resolution_regex is a regular # expression that must set the unnamed variable $1 to the # requested resolution. It is checked for a match as: # m/$regex/s # # For example, if one issued in the log message the # resolution command: # # status 547: resolved fixed # # Then the resolution_status_resolution_regex is expected # to match "fixed" resolution_status_resolution_regex => '^\s*status.*?:\s*\S+\s+(\S+)' # The resolution_status_resolution_data_regex is a regular # expression that must set the unnamed variable $1 to the # additional data supplied by the resolution status. It is # checked for a match as: # m/$regex/s # # For example, if one issued in the log message the # resolution command: # # status 548: resolved duplicate 547 # # Then the resolution_status_resolution_data_regex is # expected to match "547" resolution_status_resolution_data_regex => '^\s*status.*?:\s*\S+\s+\S+\s+(\S+)', },
Some bug-trackers may report resolution-related information with a token that contains spaces. For example, Mantis 1.0.0 offers the resolution "unable to reproduce". This would make it difficult to develop regular expressions that will correctly identify the new status and resolution. This resolution could instead be written in a log message by the user as "unable_to_reproduce" and have Scmbug configured to replace all underscores ("_") with spaces (" ") using the resolution_status_convert policy, as shown in Figure 4-25.
Figure 4-25. Regular expressions defining a resolution status character conversion.
# The resolution_status_* information can have all of the # following characters converted according to a regular # expression. This is useful in addressing the limitation # of some bug-trackers that report a resolution-related # information with a token that contains spaces. For # example: # # "unable to reproduce" in Mantis. resolution_template => { resolution_status_convert => { enabled => 0, # Regular expressions that will be applied to convert # the characters of all resolution_status_* # information. It is applied for substitution as: # # s/$convert_from/$convert_to/g resolution_status_convert_from => '_', resolution_status_convert_to => ' ' }, }
This template can be customized when the Scmbug codebase is configured, prior to installation. The arguments --with-resolution-template-bugid-regex=<regular_expression>, --with-resolution-template-bugid-split-regex=<regular_expression>, --with-resolution-template-status-regex=<regular_expression>, --with-resolution-template-status-resolution-regex=<regular_expression>, --with-resolution-template-status-resolution-data-regex=<regular_expression>, --with-resolution-template-status-convert-from-regex=<regular_expression>, and --with-resolution-template-status-convert-to-regex=<regular_expression> can be passed to configure, shown in Figure 8-4.
Figure 4-26. Example log message that changes the resolution status of multiple bugs.
status 548,622: reopened status 755: resolved worksforme bug 547:Implemented automatic status resolution as a new policy. This seems to work but will need improvements in the testsuite. status 547: REsolved fIXED status 548: RESOLVED duplicate 547 status 647: assigned unassigned@mkgnu.net
![]() | Figure 4-26 does not show multiple examples. It shows one example of one log message. |
The resolution status and resolution descriptions are verified case insensitive by default, as shown in Figure 4-26. This can be controlled using the resolution_status_case_sensitive_verification variable, as shown in Figure 4-27.
Figure 4-27. Case sensitive resolution verification variable.
# Apply a case sensitive resolution and resolution status verification resolution_status_case_sensitive_verification => 0,
A resolution description must refer to bug ids filed against the SCM system's associated product name in the bug-tracking system. This behavior is optional and can be configured in the glue configuration file using the resolution_valid_product_name policy variable, as shown in Figure 4-28.
Figure 4-28. Valid product name policy in reference to bug resolution.
resolution_template => { # The bugs whose resolution status will be changed must be # filed against a valid product name. resolution_valid_product_name => 1, },
The SCM user issuing a bug resolution must be the owner of the bug against which subsequent integration requests will be issued. This behavior is optional and can be configured in the glue configuration file using the resolution_valid_bug_owner policy variable, as shown in Figure 4-29.
There are plans to support autolinkification.