tcms.issuetracker.types module

This module implements Kiwi TCMS interface to external issue tracking systems. Refer to each implementor class for integration specifics!

class tcms.issuetracker.types.Bugzilla(bug_system)[source]

Bases: tcms.issuetracker.base.IssueTrackerType

Support for Bugzilla. Requires:

Api_url:
  • the XML-RPC URL for your Bugzilla instance
Api_username:
  • a username registered in Bugzilla
Api_password:
  • the password for this username

You can also provide the BUGZILLA_AUTH_CACHE_DIR setting (in product.py) to control where authentication cookies for Bugzilla will be saved. If this is not provided a temporary directory will be used each time we try to login into Bugzilla!

add_testexecution_to_issue(executions, issue_url)[source]

When linking defect URLs to Test Execution results there is a ‘Add comment to Issue tracker’ checkbox. If selected this method is called. It should ‘link’ the existing defect back to the TE/TR which reproduced it.

Usually this is implemented by adding a new comment pointing back to the TR/TE via the internal RPC object.

Executions:
  • iterable of TestExecution objects
Issue_url:
  • the URL of the existing defect
report_issue_from_testexecution(execution, user)[source]

When marking TestExecution results inside a Test Run there is a Report link. When the Report link is clicked this method is called to help the user report an issue in the IT.

This is implemented by constructing an URL string which will pre-fill bug details like steps to reproduce, product, version, etc from the test case. Then we open this URL into another browser window!

Execution:TestExecution object
User:User object
Returns:
  • string - URL
class tcms.issuetracker.types.GitHub(bug_system)[source]

Bases: tcms.issuetracker.base.IssueTrackerType

Support for GitHub. Requires:

Base_url:
  • URL to a GitHub repository for which we’re going to report issues
Api_password:
  • GitHub API token.

Note

You can leave the api_url and api_username fields blank because the integration code doesn’t use them!

add_testexecution_to_issue(executions, issue_url)[source]

When linking defect URLs to Test Execution results there is a ‘Add comment to Issue tracker’ checkbox. If selected this method is called. It should ‘link’ the existing defect back to the TE/TR which reproduced it.

Usually this is implemented by adding a new comment pointing back to the TR/TE via the internal RPC object.

Executions:
  • iterable of TestExecution objects
Issue_url:
  • the URL of the existing defect
is_adding_testcase_to_issue_disabled()[source]

When is linking a TC to a Bug report disabled? Usually when not all of the required credentials are provided.

Returns:bool
report_issue_from_testexecution(execution, user)[source]

GitHub only supports title and body parameters

class tcms.issuetracker.types.Gitlab(bug_system)[source]

Bases: tcms.issuetracker.base.IssueTrackerType

Support for Gitlab. Requires:

Base_url:URL to a GitLab repository for which we’re going to report issues
Api_url:URL to GitLab instance. Usually gitlab.com!
Api_password:GitLab API token.

Note

You can leave api_username field blank because the integration code doesn’t use it!

add_testexecution_to_issue(executions, issue_url)[source]

When linking defect URLs to Test Execution results there is a ‘Add comment to Issue tracker’ checkbox. If selected this method is called. It should ‘link’ the existing defect back to the TE/TR which reproduced it.

Usually this is implemented by adding a new comment pointing back to the TR/TE via the internal RPC object.

Executions:
  • iterable of TestExecution objects
Issue_url:
  • the URL of the existing defect
is_adding_testcase_to_issue_disabled()[source]

When is linking a TC to a Bug report disabled? Usually when not all of the required credentials are provided.

Returns:bool
report_issue_from_testexecution(execution, user)[source]

When marking TestExecution results inside a Test Run there is a Report link. When the Report link is clicked this method is called to help the user report an issue in the IT.

This is implemented by constructing an URL string which will pre-fill bug details like steps to reproduce, product, version, etc from the test case. Then we open this URL into another browser window!

Execution:TestExecution object
User:User object
Returns:
  • string - URL
class tcms.issuetracker.types.JIRA(bug_system)[source]

Bases: tcms.issuetracker.base.IssueTrackerType

Support for JIRA. Requires:

Api_url:
  • the API URL for your JIRA instance
Api_username:
  • a username registered in JIRA
Api_password:
  • the password for this username

Additional control can be applied via the JIRA_OPTIONS configuration setting (in product.py). By default this setting is not provided and the code uses jira.JIRA.DEFAULT_OPTIONS from the jira Python module!

add_testexecution_to_issue(executions, issue_url)[source]

When linking defect URLs to Test Execution results there is a ‘Add comment to Issue tracker’ checkbox. If selected this method is called. It should ‘link’ the existing defect back to the TE/TR which reproduced it.

Usually this is implemented by adding a new comment pointing back to the TR/TE via the internal RPC object.

Executions:
  • iterable of TestExecution objects
Issue_url:
  • the URL of the existing defect
classmethod bug_id_from_url(url)[source]

Jira IDs are the last group of chars at the end of the URL. For example https://issues.jenkins-ci.org/browse/JENKINS-31044

report_issue_from_testexecution(execution, user)[source]

For the HTML API description see: https://confluence.atlassian.com/display/JIRA050/Creating+Issues+via+direct+HTML+links

class tcms.issuetracker.types.Redmine(bug_system)[source]

Bases: tcms.issuetracker.base.IssueTrackerType

Support for Redmine. Requires:

Api_url:
  • the API URL for your Redmine instance
Api_username:
  • a username registered in Redmine
Api_password:
  • the password for this username
add_testexecution_to_issue(executions, issue_url)[source]

When linking defect URLs to Test Execution results there is a ‘Add comment to Issue tracker’ checkbox. If selected this method is called. It should ‘link’ the existing defect back to the TE/TR which reproduced it.

Usually this is implemented by adding a new comment pointing back to the TR/TE via the internal RPC object.

Executions:
  • iterable of TestExecution objects
Issue_url:
  • the URL of the existing defect
static find_issue_type_by_name(project, name)[source]

Return a Redmine tracker matching name (‘Bug’).

Note

If there is no match then return the first one!

find_project_by_name(name)[source]

Return a Redmine project which matches the given product name.

Note

If there is no match then return the first project in Redmine.

report_issue_from_testexecution(execution, user)[source]

When marking TestExecution results inside a Test Run there is a Report link. When the Report link is clicked this method is called to help the user report an issue in the IT.

This is implemented by constructing an URL string which will pre-fill bug details like steps to reproduce, product, version, etc from the test case. Then we open this URL into another browser window!

Execution:TestExecution object
User:User object
Returns:
  • string - URL
tcms.issuetracker.types.from_name(name)[source]

Return the class which matches name if it exists inside this module or raise an exception.