rhevm-qe-automation/pytest_jira

jira_issue fixture should return issue with metadata

Closed this issue · 12 comments

I propose that the jira_issue fixture will return a JiraIssue model which will hold metadata in its attributes (like description, dates etc.).

This will enable a richer experience for both returning detailed skip messages, more complex conditional statements and more, all using data we already fetch but do nothing with.

The class will have a __bool__ dunder which will make previously the class backwards compatible with previous conditional checks on the fixture reply.

If you approve I'd be happy to put a PR for this.

WDYT?

Big thumb for this!!

Cool, I'll put up a PR

Starting to take a look at this, there's a question of how deep we want to go the rabbit hole.

There are A LOT of fields per issue. These are all the root types. I marked the ones I think are MVP:

  • issuetype
  • duedate
  • components
  • status
  • creator
  • fixVersions
  • resolution
  • resolutiondate
  • summary
  • assignee
  • versions
  • updated
  • created
  • reporter
  • priority
  • labels
  • timeestimate
  • aggregatetimeoriginalestimate
  • issuelinks
  • workratio
  • watches
  • lastViewed
  • project
  • timeoriginalestimate
  • timetracking
  • security
  • timespent
  • attachment
  • subtasks
  • aggregateprogress
  • environment
  • progress
  • comment
  • votes
  • worklog

Also there can be custom fields, all prefixed with customfield_

Rant: Thanks Atlassian for can't deciding between snake case or camel case in your response, and just sticking with the unreadable nospaceslowercase...

I would stick to most common ones, which are mostly used in decision making to skip or not-skip the issue.

Maybe we should re-add the Jira dependency. It didn't make much sense to use it just for authentication but it does for returning rich data, and also it is pretty well documented and common. WDYT?

On one hand I like the fact that this plugin became more lightweight by replacing jira module with requests.

But if it leads us to reinvent existing code, I would rather step back and use jira dependency instead.

So, yes I agree with your statement.

awesome. i'll make the changes. just to make sure, we're talking about using https://pypi.org/project/jira/, correct?

gs202 commented

Hi @lukas-bednar i'd like to take this feature.
Thought about adding additional Boolean addoption which will return the JiraIssue

gs202 commented

I think that this can be closed

Closed with #108