Labels trigger Jira issue creation #265
Conversation
These tests don't affect Jira anymore, so no need to talk about Jira.
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #265 +/- ##
==========================================
+ Coverage 83.71% 89.45% +5.74%
==========================================
Files 38 38
Lines 2916 2778 -138
Branches 306 282 -24
==========================================
+ Hits 2441 2485 +44
+ Misses 442 264 -178
+ Partials 33 29 -4
☔ View full report in Codecov by Sentry. |
nedbat
force-pushed
the
nedbat/label-for-jira
branch
from
22d79b5 to
6a2f954
Compare
openedx_webhooks/settings.py
Outdated
There was a problem hiding this comment.
I'm curious about why you didn't just stick to the module namespace. That's a pattern common in Django so it was familiar. What you've done is not complicated but I'm just trying to understand what lead you in this direction? Especially once you pull the test settings into their on settings file.
There was a problem hiding this comment.
I did this when I thought we'd have parallel environment variables for Jira settings, and it was awkward to parse them and mock them. Now we aren't doing that, this does seem over-complicated. I can undo it.
There was a problem hiding this comment.
Yea, I think let's un-do it. You want to do that in this PR or a follow-up?
| # A label of jira:xyz means we want a Jira issue in the xyz Jira. | ||
| label_names = set(lbl["name"] for lbl in pr["labels"]) | ||
| desired.jira_nicks = {name.partition(":")[-1] for name in label_names if name.startswith("jira:")} | ||
|
|
||
| desired.jira_initial_status = "Needs Triage" |
There was a problem hiding this comment.
This is an assumption about what states are expected in any given Jira project that is added. We should probably document this somewhere. ie. "Setting up a Jira Project to work with openedx-webhooks". I'm also okay with something small in the README for now.
There was a problem hiding this comment.
As it turns out, we never use this value at the moment. We'll get issues created, and then fix up the initial status somehow. Ideally, we wouldn't have to specify the initial status, the project could just set it implicitly.
Full disclosure: I haven't thought hard about what rescanning should do now, and haven't added the new label->Jira logic into the rescan tests.
nedbat
force-pushed
the
nedbat/label-for-jira
branch
from
6a2f954 to
8ebae19
Compare
This has the basic functionality, except:
The commits are roughly partitioned into separate work, but I had to re-think some things about how the jira ticket is stashed in the comments, and I didn't go back to try to make it a straight path.