Hello, this feels like a bug but I'm not sure. I have a Jira call that I am trying to make. It's to get the list of bugs in a project and their changelog history so I can get the creation date and timstamp that a label gets set. I am using the following cURL command
/usr/bin/curl \
-s -u user@company.com:APIKEY -X GET \
-H "Content-Type: application/json" \
https://company.atlassian.net/rest/api/2/search?expand=changelog&jql=project=KEY%20and%20issueType=BUG
This is not pulling up all bugs in the project KEY, it's pulling up all jiras period, in the jira instance. Replacing %20 with + doesn't change anything, it still results in the jql being ignored.
Now if I swap expand=changelog
and jql=project=KEY%20and%20issueType=BUG
so that it's
/usr/bin/curl \
-s -u user@company.com:APIKEY -X GET \
-H "Content-Type: application/json" \
https://company.atlassian.net/rest/api/2/search?jql=project=KEY%20and%20issueType=BUG&expand=changelog
it will pull down all bugs in the project KEY, but it does not expand the changelog, resulting in it not including the bug histories of the bug that I am trying to get, which is what I want
Now if I paste either of the URIs in the browser, they work just fine, so it's something about how cURL is handling it, so I'm not sure what I'm missing here.
Any suggestions? Any assistance would be appreciated.
I figured it out. I used the --get and the --data parameters to move the GET params out of the URL.
from cURL's manpage
-G, --get
When used, this option will make all data specified with -d, --data, --data-binary or --data-urlen‐
code to be used in an HTTP GET request instead of the POST request that otherwise would be used. The
data will be appended to the URL with a '?' separator.
If used in combination with -I, --head, the POST data will instead be appended to the URL with a HEAD
request.
If this option is used several times, only the first one is used. This is because undoing a GET
doesn't make sense, but you should then instead enforce the alternative method you prefer.
So changed my cURL call to
/usr/bin/curl \
-s -u user@company.com:APIKEY -X GET --get \
-H "Content-Type: application/json" \
--data 'jql=project=KEY+and+issueType=BUG&expand=changelog' \
'https://bymason.atlassian.net/rest/api/2/search'
And that seems to be working.
It not working in the URI itself has got to be a bug in cURL
I figured it out. I used the --get and --data arguments to move the GET params into their arguments and out of the URI. From the cURL manpage
-G, --get
When used, this option will make all data specified with -d, --data, --data-binary or --data-urlen‐
code to be used in an HTTP GET request instead of the POST request that otherwise would be used. The
data will be appended to the URL with a '?' separator.
If used in combination with -I, --head, the POST data will instead be appended to the URL with a HEAD
request.
If this option is used several times, only the first one is used. This is because undoing a GET
doesn't make sense, but you should then instead enforce the alternative method you prefer.
So my new curl call to the API is
/usr/bin/curl -s -u user@company.com:APIKEY -X GET --get \
-H "Content-Type: application/json" \
--data 'jql=project=KEY+and+issueType=BUG&expand=changelog' \
'https://bymason.atlassian.net/rest/api/2/search'
Not sure why the params don't work in the argument directly. Seems like a bug. But this works
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear @chrisyeem ,
As far as I can see, everything is correct. So the source of your issue could be curl, itself. It could be linked to the false library. Or the charset of your shell is suppressing the characters.
You can try to rebuild curl on your own from source and install at /usr/local/bin in parallel.
Have you tried another Linux distribution?
Just to be sure: /rest/api/2 is the path to server, not cloud. That's not the cause, or?
So long
Thomas
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
For the /rest/api/2 question, I just followed what I saw in https://developer.atlassian.com/server/jira/platform/jira-rest-api-examples/ which I only have just realized is for server, not cloud, but that part was always working, so I don't know why that is. I am on cloud. What should the path be for cloud?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.