Jira Issue Handler - SatelliteQE/robottelo GitHub Wiki
Robottelo uses Jira-aware collection helpers in robottelo/utils/issue_handlers
and pytest_plugins/issue_handlers.py.
Issue state affects both test authoring and collection behavior, so it is worth understanding how the Jira helpers and pytest plugins interact.
- resolves Jira issue state through the Jira helper module
- supports
is_open(<ISSUE>)checks in test code - collects issue usage from test docstrings and markers
- dynamically deselects tests when issue state says they should not run
- caches Jira lookups to reduce repeated API calls
Use is_open('SAT-12345') inside test logic when behavior truly depends on the
current state of a Jira issue.
Example:
from robottelo.utils.issue_handlers import is_openThis is a helper function, not a pytest marker.
Use it when the test logic genuinely needs an issue-dependent branch. Do not use it as a substitute for writing down issue linkage in the docstring.
The underlying Jira helper module exposes a few important concepts:
-
is_open_jira()checks whether an issue should be treated as open -
are_all_jira_open()andare_any_jira_open()support multi-issue checks -
should_deselect_jira()decides whether collection should remove a test - cached issue data is stored in the configured Jira cache file
The Jira helper layer uses a local status cache so collection does not need to hit the Jira API for every run. That matters because large functional suites can touch many issue references.
These concepts are not the same thing.
- an issue can be treated as open for conditional test logic
- a test can be deselected only in the narrower case handled by the deselection logic
That distinction matters when reading old tests or collection behavior.
Two testimony fields are especially important:
-
:BlockedBy:- associates the test with blocking Jira issues -
:Verifies:- associates the test with issues the test covers
The metadata plugin converts these docstring fields into pytest markers during collection:
blocked_byverifies_issues
In normal test authoring, prefer the docstring fields rather than manually adding those markers yourself.
The docstrings are the stable authoring interface. The markers are mostly an implementation detail of collection and reporting.
--blocked-by--verifies-issues--jira-comments
These options filter collection using the Jira-linked metadata gathered from docstrings.
Robottelo also supports commenting test results back onto Jira issues.
This flow requires both:
-
ENABLE_COMMENT: trueinconf/jira.yaml - the
--jira-commentspytest option
That double opt-in exists to reduce accidental commenting.
The Jira comments plugin works from tests linked through :Verifies: and
:BlockedBy: metadata, unless you explicitly override the issue list via the
CLI option.
The current default Jira config also includes:
COMMENT_TYPECOMMENT_VISIBILITYISSUE_STATUS
These influence how comments are posted and on which Jira states commenting is allowed.
The issue-handler plugin can add pytest.mark.deselect(reason=<ISSUE>)
dynamically during collection when an issue state requires the test to be
removed from the run.
That marker is typically plugin-managed, not something contributors add in normal test authoring.
- the test is intended to demonstrate coverage for a specific Jira issue
- you want issue-linked reporting and optional Jira comment behavior
- the test is valid, but a known Jira issue is preventing it from being usable
- you want collection logic to take issue state into account
- the test body really needs a conditional path due to current issue state
- the condition is temporary and tied to product behavior, not just collection
Avoid overusing is_open() for situations that should be expressed as metadata.
| Need | Recommended mechanism |
|---|---|
| temporary issue-dependent branch in test logic | is_open() |
| record that a test verifies an issue | :Verifies: |
| record that a test is blocked by an issue | :BlockedBy: |
| remove tests from collection based on Jira state | let the plugin handle it |
Usually no. Put the information in the docstring fields and let the metadata plugin derive the markers.
Common reasons:
-
--jira-commentswas not provided -
ENABLE_COMMENTis still false inconf/jira.yaml - the Jira issue is not in one of the configured
ISSUE_STATUSvalues - there were no linked
:Verifies:or:BlockedBy:issues for the test run