Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jipdate shouldn't try to update issues with empty comments #50

Open
pm215 opened this issue Oct 1, 2021 · 1 comment
Open

jipdate shouldn't try to update issues with empty comments #50

pm215 opened this issue Oct 1, 2021 · 1 comment
Labels

Comments

@pm215
Copy link

pm215 commented Oct 1, 2021

If you give jipdate -f file.txt a file which includes a section for a JIRA issue with no new comment text to add, jipdate will try to add an empty comment to the JIRA issue, provoking an HTTP 400 error from the server ("text: Comment body can not be empty!").

In more detail:

I typically have two or so JIRA tasks on the go, so I have a template file that looks like this:

# For doing automated JIRA updates weekly
# EDITOR=/bin/true [email protected] ~/linaro/jipdate/jipdate.py -f ~/jipdate.txt

[UM-2]
# Header: QEMU Upstream Maintainership
# Type: Epic
  + Stuff I did on this issue
[QEMU-406]
# Header: QEMU support for MVE
# Type: Epic
  + Stuff I did on this other issue

and every week I update the bullet-point list of stuff before running the jipdate command

EDITOR=/bin/true [email protected] ~/linaro/jipdate/jipdate.py -f ~/jipdate.txt

Occasionally I only work on one of my 2 active JIRA tasks during the week. If I do the "obvious" thing and just leave that part blank, so that there is a "[FOO-9434]" tag line but then no non-comment lines after it, or only blank lines after it, then jipdate will try to update the JIRA issue with an empty comment, and the server doesn't like it:

$ EDITOR=/bin/true [email protected] ~/linaro/jipdate/jipdate.py -f ~/jipdate.txt
These JIRA cards will be updated as follows:

[UM-2]
    + Worked through my code-review backlog
    + Noticed that we never got round to making our emulated GICv3 support having redistributors in more than one contiguous region; this prevents using more than 123 CPUs with the virt board. Sent out a patchset which adds the necessary handling.
    + Generally trying to tie off loose ends pre-holiday :-)
[QEMU-406]


Server to update: https://linaro.atlassian.net

Are you sure you want to update Jira with the information above? [y/n] y
Traceback (most recent call last):
  File "/home/petmay01/linaro/jipdate/jipdate.py", line 535, in main
    issues
UnboundLocalError: local variable 'issues' referenced before assignment

During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/petmay01/linaro/jipdate/jipdate.py", line 543, in <module>
    main(sys.argv)   
  File "/home/petmay01/linaro/jipdate/jipdate.py", line 538, in main
    parse_status_file(jira, filename, None)
  File "/home/petmay01/linaro/jipdate/jipdate.py", line 408, in parse_status_file
    update_jira(jira, issue, comment, transition)
  File "/home/petmay01/linaro/jipdate/jipdate.py", line 160, in update_jira
    jira.add_comment(i, c)
  File "/home/petmay01/.local/lib/python3.6/site-packages/jira/client.py", line 106, in wrapper
    result = func(*arg_list, **kwargs)
  File "/home/petmay01/.local/lib/python3.6/site-packages/jira/client.py", line 1645, in add_comment
    r = self._session.post(url, data=json.dumps(data))
  File "/home/petmay01/.local/lib/python3.6/site-packages/jira/resilientsession.py", line 175, in post
    return self.__verb("POST", url, **kwargs)
  File "/home/petmay01/.local/lib/python3.6/site-packages/jira/resilientsession.py", line 168, in __verb
    raise_on_error(response, verb=verb, **kwargs)
  File "/home/petmay01/.local/lib/python3.6/site-packages/jira/resilientsession.py", line 54, in raise_on_error
    r.status_code, error, r.url, request=request, response=r, **kwargs
jira.exceptions.JIRAError: JiraError HTTP 400 url: https://linaro.atlassian.net/rest/api/2/issue/QEMU-406/comment
        text: Comment body can not be empty!

        response headers = {'Server': 'AtlassianProxy/1.19.3.1', 'cache-control': 'no-cache, no-store, no-transform', 'Content-Type': 'application/json;charset=UTF-8', 'Strict-Transport-Security': 'max-age=315360000; includeSubDomains; preload', 'Date': 'Fri, 01 Oct 2021 16:00:37 GMT', 'ATL-TraceId': 'XXX', 'x-arequestid': 'XXX', 'x-aaccountid': 'XXX', 'X-XSS-Protection': '1; mode=block', 'Transfer-Encoding': 'chunked', 'timing-allow-origin': '*', 'x-envoy-upstream-service-time': '86', 'X-Content-Type-Options': 'nosniff', 'Connection': 'close', 'Expect-CT': 'report-uri="https://web-security-reports.services.atlassian.com/expect-ct-report/global-proxy", enforce, max-age=86400'} 
        response text = {"errorMessages":[],"errors":{"comment":"Comment body can not be empty!"}}

(I've XXXed out things like accountid just in case they are sensitive data.)

It would be nice if jipdate noticed that there was no actual content for the issue, and didn't try to update it.

(The workaround is simple: temporarily comment out the [FOO-4343] tag for the issue that wouldn't have any content.)

@jbech-linaro
Copy link
Collaborator

Hi @pm215 , thanks for submitting the issue. For sure sounds like a bug. I will try to fix it, but I cannot say when. I have a few other things in the pipe that has higher priority, so in the mean time, please continue with the workaround.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants