Jira Issue Handler - SatelliteQE/robottelo GitHub Wiki

Jira issue handler

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.

What the issue handler does

  • 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

is_open()

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_open

This 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.

Core Jira helpers

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() and are_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

Cache behavior

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.

What “open” and “deselect” mean here

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.

Docstring fields that integrate with Jira

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_by
  • verifies_issues

In normal test authoring, prefer the docstring fields rather than manually adding those markers yourself.

Why docstrings are preferred

The docstrings are the stable authoring interface. The markers are mostly an implementation detail of collection and reporting.

Related pytest options

  • --blocked-by
  • --verifies-issues
  • --jira-comments

These options filter collection using the Jira-linked metadata gathered from docstrings.

Jira comments

Robottelo also supports commenting test results back onto Jira issues.

This flow requires both:

  1. ENABLE_COMMENT: true in conf/jira.yaml
  2. the --jira-comments pytest option

That double opt-in exists to reduce accidental commenting.

What gets commented

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_TYPE
  • COMMENT_VISIBILITY
  • ISSUE_STATUS

These influence how comments are posted and on which Jira states commenting is allowed.

Deselect behavior

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.

Practical authoring guidance

Use :Verifies: when

  • the test is intended to demonstrate coverage for a specific Jira issue
  • you want issue-linked reporting and optional Jira comment behavior

Use :BlockedBy: when

  • 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

Use is_open() when

  • 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.

When to use what

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

FAQ

Should I hand-write blocked_by or verifies_issues as pytest markers?

Usually no. Put the information in the docstring fields and let the metadata plugin derive the markers.

Why didn’t my Jira comment get posted?

Common reasons:

  • --jira-comments was not provided
  • ENABLE_COMMENT is still false in conf/jira.yaml
  • the Jira issue is not in one of the configured ISSUE_STATUS values
  • there were no linked :Verifies: or :BlockedBy: issues for the test run
⚠️ **GitHub.com Fallback** ⚠️