-
Suggestion
-
Resolution: Unresolved
-
None
-
0
-
1
-
As a user I should be able to add notes to GitHub, and the DVCS connector would make updates to the JIRA issue.
One common scenario is:
1. Make a commit in GitHub, and the developer forgets to enter the the JIRA issue in the comment.
2. DVCS scans the commits and doesn't add the commit to the JIRA issue because there was no issue entered in the GitHub comment.
3. The developer goes back to GitHub, and adds a comment/note with the JIRA issue.
4. DVCS should scan subsequent comment/notes and add a commit to the JIRA issue.
- is related to
-
- Future Consideration
- links to
- mentioned in
-
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page")
Page
Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSWSERVER-14360] As a user I should be able to add notes to GitHub, and the DVCS connector would make updates to the JIRA issue
Fred Cassirer
added a comment - I think I have a similar if not exact request as Erik. It is not clear where DVCS hooks are applied to various GitHub json payloads.
To be clear, it would be very useful to have examples or documentation that says when DVCS tagging is applied:
- In the Title (1st line) of a Pull Request? (Seems to work)
- In the body of a Pull Request? (Doesn't seem to work)
- In a commit message? (Yes, at least the first one)
- In a commit (update to a PR) to the fork'd repo of an open pull request? (no)
- In a followup comment to a GitHub pull request (issue-comment)? (Doesn't seem to work)
- In second or third instances within the same message? (Doesn't seem to work)
ex;
ABC-123 ABC-345 DEF-789 #comment add this to ABC and DEF issues, no problem
XYZ-123 #comment this is ignored ... apparently only one line is parsed by DVCS ... seems oddly restrictive.
Not exhaustive testing, however, from a users perspective, this is all seriously confusing.
Anyone interacting with this will quickly get frustrated, and at best, confused.
When you enroll an organization/team into GitHub (or possibly Bitbucket), it creates a repo hook. For GitHub it creates two hooks, one for sending push
payloads and one with push/PR/Comment/PR-comment and some other events. Given the above list, it seems as though DVCS should be slogging through the "body" attributes in the various json payloads and applying the magic.
Also, is there a way to turn on debug on the Jira instance to get more info in the logs?
Thanks for any insight.
-Fred Cassirer
Fred Cassirer
added a comment - I think I have a similar if not exact request as Erik. It is not clear where DVCS hooks are applied to various GitHub json payloads.
To be clear, it would be very useful to have examples or documentation that says when DVCS tagging is applied:
In the Title (1st line) of a Pull Request? (Seems to work)
In the body of a Pull Request? (Doesn't seem to work)
In a commit message? (Yes, at least the first one)
In a commit (update to a PR) to the fork'd repo of an open pull request? (no)
In a followup comment to a GitHub pull request (issue-comment)? (Doesn't seem to work)
In second or third instances within the same message? (Doesn't seem to work)
ex;
ABC-123 ABC-345 DEF-789 #comment add this to ABC and DEF issues, no problem
XYZ-123 #comment this is ignored ... apparently only one line is parsed by DVCS ... seems oddly restrictive.
Not exhaustive testing, however, from a users perspective, this is all seriously confusing.
Anyone interacting with this will quickly get frustrated, and at best, confused.
When you enroll an organization/team into GitHub (or possibly Bitbucket), it creates a repo hook. For GitHub it creates two hooks, one for sending push
payloads and one with push/PR/Comment/PR-comment and some other events. Given the above list, it seems as though DVCS should be slogging through the "body" attributes in the various json payloads and applying the magic.
Also, is there a way to turn on debug on the Jira instance to get more info in the logs?
Thanks for any insight.
-Fred Cassirer
As found by Fred Cassirer, these two issues are very similar. We need to fix old commit that did not properly mentioned a JIRA issue (either is was not there or had a wrong number).