I want to design an issue workflow that is well integrated with GitHub (or more generally, with the DVCS that the project is using).
Specifically, I want to prevent someone from marking the story as "Done" until all pull requests have been closed.
I have read a bit about Script Runner scripts and understand that development debugging is a bit painful; however, I'm willing to learn Groovy and do some experimentation. I've even browsed the source for the DVCS plugin and I am familiar with some of its classes and interfaces.
My problem is that I don't know how to get access to the DVCS plugin .. the Groovy script's binding contains an issue object, but JIRA's Issue class has no direct references to plugin-related objects. There is a DVCS PullRequestService interface, but there's no way for me to access an implementation of that interface given only an Issue.
What's the best way for me to get started? I would imagine that this is a fairly common use case; perhaps someone else in the JIRA community has done it before.
P.S. I noticed that JIRA has canned conditions for "no open Crucible reviews" and "no open changesets" – but neither of these works with the DVCS plugin. That's a great pity, because otherwise my task would be done and I wouldn't need to learn Groovy or experiment!
If you used one of the many "script runner" or "groovy" tags you would get better/quicker responses. No one follows either of the tags you used, precisely because everyone uses them. Rant over.
Why do you think debugging is painful? I think it's easy, it's exactly the same as with a java plugin... attach your debugger, set your breakpoints, debug.
You can get components from other plugins using the method here: https://jamieechlin.atlassian.net/wiki/display/GRV/Scripting+Other+Plugins
But yes you will need to be familiar with the API of the DVCS plugin.
It's an interesting question but I'm not sure it's a great idea... anyone can create a pull request pretty much, which will block closing the issue.
Thank you for pointing me in the right direction! I've tagged my post accurately. I suppose "painful" is relative -- as someone who's not deeply embedded in the Java ecosystem and accustomed to consuming Jira purely as an app, it'll require a few hours of my time to install all of the necessary dependencies. Well worth the trouble if I can get the plugin I need authored. Regarding the wisdom of adding this condition -- the DVCS API seems pretty data-rich; I will probably only block transition on the existence of open PRs to master, which shouldn't be too onerous. Agreed that this could "jam the works" of a story being completed, but I'm applying this workflow to some closed-source repositories whose development teams tend to behave themselves. I'd rather people be aware of the open PR and investigate it than leave it to hang out for months or days after the story is "released."
I believe this interface and its backing impl would be precisely what I need to grab: https://bitbucket.org/atlassian/jira-dvcs-connector/src/93981e9520bfdc518ab39bcb3547a043cb626100/jira-dvcs-connector-plugin/src/main/java/com/atlassian/jira/plugins/dvcs/service/api/DvcsPullRequestService.java?at=master#cl-16
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs