This project is read-only.

4. Configuring the SA Project Link

Previous step: 3. Configure SmartAssembly Sync for JIRA®.

For each SA Project Link you created earlier, complete the configuration of the link.

  1. Reload the SA Project Link in JIRA.
  2. A set of default extra information (in JSON format) appears in the Description.
    The JSON was added automatically when you ran SmartAssembly Sync for JIRA from the command line in the previous step.
    SA Project Link issue
  3. Click Edit.
  4. Change EarliestBuildDate to the date of the earliest build for which you want to import bugs.
  5. Ignore the ReportsAreAutomaticallySent field.
    ReportsAreAutomaticallySent is a field used internally at Red Gate Software, and is not relevant to the open-sourced version of SmartAssembly Sync for JIRA.
  6. If the project represents a dependency shared between multiple products, and you want to raise linked bugs in those other products too, enter the SmartAssembly Project Names of those other products in ProductDependencies.
  7. If your source code can be searched in OpenGrok, edit OpenGrokSettings with the path the code is checked out to on the build server when it is compiled.
    SmartAssembly Sync for JIRA can then link to the relevant source code from bug reports:
      "OpenGrokSettings": [
        {
          "OpenGrokProject": "Open_Grok_Project_Name",
          "RegEx": "d:\\\\path\\\\to\\\\source\\\\.*?\\\\(.*)"
        }
      ],
  8. If you have entered this project in the ProductDependencies for another project, change ProductAssemblies to a list of DLLs that should be reported to this project.
  9. If you want to be able to ignore bugs raised by your testing framework, for example, set PropertyFilters to a value that your testing framework will send with error reports, so they can be ignored.
    For example:
      "PropertyFilters": {
          "Email": "testuser@example.com"
      },

    In this case, any incoming error reports containing the value testuser@example.com for the Email field will not be imported.
    If you include more than one filter, the report is ignored if any of the filters match.
  10. Some types of exception are not specific enough to classify them as the same bug. In these cases, change ExceptionTypeNameToReportHasherSourceCode to some C# source code that should be executed while importing. The return value from the C# will be added to the report hash, thereby increasing the granularity of the bugs.
    For example, SQLExceptions are not specific enough, but the C# below will return a SQL error number from the report, which will be added to the report hash. The report hash is used to determine whether bugs are the same as previously-raised bugs, and so different SQL error numbers will be imported as different bugs.
      "ExceptionTypeNameToReportHasherSourceCode": {
        "[System.Data]System.Data.SqlClient.SqlException": " report => {string p = report.GetCustomProperty(\"SqlErrorNumber\"); return p != null ? \"Number: \" + p : \"unknown\"; }"
      },
  11. If you rename a method in your source code, set the mapping from the old name to the new name in MethodTypeNameMapper.
    Setting the mapping ensures that a new bug is not opened unnecessarily just because a method has been renamed.
    In the example below, errors from …TFS2005 and …TFS2008 are counted as being identical errors in …TFS*.
      "MethodTypeNameMapper": {
        "[RedGate.SQLSourceControl.Engine.SrcC.TFS2005]":   
        "[RedGate.SQLSourceControl.Engine.SrcC.TFS*]",   
        "[RedGate.SQLSourceControl.Engine.SrcC.TFS2008]": 
        "[RedGate.SQLSourceControl.Engine.SrcC.TFS*]"
      },
  12. Similarly, if you change the name of an exception, set this in ExceptionTypeNameMapper.
  13. Click Update.
    Edit the SA Project Link description
  14. Repeat the steps on this page for every SA Project Link issue you have created.

Next step: 5. Test SmartAssembly Sync for JIRA.

Last edited Apr 11, 2011 at 4:51 PM by dnas2, version 8

Comments

No comments yet.