jira_issue fixture should return issue with metadata

rhevm-qe-automation / pytest_jira

py.test plugin to integrate with JIRA

GNU General Public License v2.0

29 stars 25 forks source link

jira_issue fixture should return issue with metadata #94

Closed liiight closed 4 years ago

liiight commented 6 years ago

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?

lukas-bednar commented 6 years ago

Big thumb for this!!

liiight commented 6 years ago

Cool, I'll put up a PR

liiight commented 6 years ago

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:

[x] issuetype
[x] duedate
[x] components
[x] status
[x] creator
[x] fixVersions
[x] resolution
[x] resolutiondate
[x] summary
[x] assignee
[x] versions
[x] updated
[x] created
[x] reporter
[x] priority
[x] 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...

lukas-bednar commented 6 years ago

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

liiight commented 5 years ago

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?

liiight commented 5 years ago

@lukas-bednar ping

lukas-bednar commented 5 years ago

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.

liiight commented 5 years ago

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

lukas-bednar commented 5 years ago

yes

gs202 commented 5 years ago

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

gs202 commented 4 years ago

I think that this can be closed

liiight commented 4 years ago

Closed with #108