Factor GH Reason states into how associated Jira issues are closed out

[mattreid]

GH has reason states, which we might be able to use to determine how a synced Jira issue can be closed out. Today, if something is closed/dropped in GH, its Jira still gets resolved, and shows up like it was completed. It would be nice if a GH issue marked as not planned would show up in Jira as Dropped/Obsolete/Won't Do/etc, something other than Done, so it doesn't show up in queries for delivered work.
https://github.blog/changelog/2022-05-19-the-new-github-issues-may-19th-update/

[mattreid]

As an example, right here in this issue, I see a split button for closing the issue where I can mark it Closed as completed, or Closed as not planned.

[Zyzyx]

I'll look into this one next.

[Zyzyx]

Alright, we get everything we need from fedmsg to make this work. There's only 2 reasons provided by GitHub at this time like @mattreid observed, so we can map them to resolutions in Jira. Here's what I propose as a default:

• Close as completed --> Done
• Close as not planned --> Won't Do

Done and Won't Do are provided by default in Jira instances, so all instances should have them. Furthermore, Resolutions are instance wide values, they are not per-project. (values can be restricted per-project via SR behaviors but I think that's beyond most admins' needs) This design detail makes me think the mapping, if we were going to put it in the config file, should be at the Jira instance level, not the project level.

At Red Hat, we have no plans to change our resolution values. GitHub has had the same closure reasons for 2 years, so they don't change much either. We can put this in the config file, but I could also see the argument that we'd be adding options nobody really needs/uses.

[Zyzyx]

In the code today, duplicate issues are identified and closed with the Duplicate resolution. This is neat and has error handling when a state transition is attempted with a resolution that is not allowed. (i.e. setting a resolution when trying to move to In Progress) I think that particular code path should be united with the more generic state-transition code path.

It'll have no bearing on the user experience. It just makes the code a little more maintainable since state transitions in Jira will follow one path instead of 2 where one has better error handling and the other is missing it.

[mattreid]

That all sounds reasonable to me, @Zyzyx, and would solve the intent of this issue for me.

[Zyzyx]

Implementation is done, but still testing it. Got distracted with cleaning up tech debt with rbean.

[mattreid]

@Zyzyx Is there more testing to do on this before it can be merged?

[Zyzyx]

Sorry, been distracted with Scriptrunner Connect and other internal things. I'll work on this next week and have an update then.

[yrodiere]

Hey @Zyzyx , are you still working on this? Or should someone else have a look?

Thanks.

[yrodiere]

I'll take silence as a "no" and will see if something can be done.