-
-
Notifications
You must be signed in to change notification settings - Fork 887
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
Support for the new 'createmeta' API in Jira 8.4+ #1527
Conversation
Am I supposed to add a label to the PR or the admins ? |
you are right, results a different. i will work on make them similar. this is why I'm using _fetch_pages , coz it gets all metadata |
Thanks for reminding me about the paging ... I remember writing a TODO and later not looking into it. I still want to discourage you from trying to make the old API behave like the new one:
Anyway these are conceptual decisions that need to be made by the maintainers. |
It appears the original
|
Fixes: DefectDojo#6963 Depends on: pycontribs/jira#1527 If you don't have the update in the mentioned dependency than behaves as it used to - works until Jira 9 and breaks afterwards. If you update the dependency than it will continue working after Jira 9. With the updated dependency it will throw deprecation warnings on Jira versions [8.4 - 9).
Fixes: DefectDojo#6963 Depends on: pycontribs/jira#1527 If you don't have the update in the mentioned dependency than behaves as it used to - works until Jira 9 and breaks afterwards. If you update the dependency than it will continue working after Jira 9. With the updated dependency it will throw deprecation warnings on Jira versions [8.4 - 9).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would be nice if you would help the user more in the exception message
Fixes: DefectDojo#6963 Depends on: pycontribs/jira#1527 If you don't have the update in the mentioned dependency than behaves as it used to - works until Jira 9 and breaks afterwards. If you update the dependency than it will continue working after Jira 9. With the updated dependency it will throw deprecation warnings on Jira versions [8.4 - 9).
The docker image allows specifying a version so we should be able to configure a test case to run on the higher version, example: jira/.github/workflows/jira_server_ci.yml Line 20 in 1c36bcd
|
jira/client.py
Outdated
"This API have been deprecated in JIRA 8.4 and is removed in JIRA 9.0." | ||
"Use 'createmeta_issuetypes' and 'createmeta_fieldtypes' instead.", | ||
DeprecationWarning, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we probably want to change the stack level here. Unfortunately the python default isn't super helpful.
We can check this is a mocked test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I don't have a lot of experience with Python, so I don't understand what does stack level in this context mean.
Should I do something like:
warn(
"This function will fail from Jira 9+. "
"Use issue_createmeta_issuetypes or issue_createmeta_fieldtypes instead.",
DeprecationWarning,
stacklevel=2,
)
(taken from https://github.com/atlassian-api/atlassian-python-api/pull/1031/files)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep exactly right, here's a useful video explaining this situation: https://www.youtube.com/watch?v=CtFdXBEwYfk
Fixes: DefectDojo#6963 Depends on: pycontribs/jira#1527 If you don't have the update in the mentioned dependency than behaves as it used to - works until Jira 9 and breaks afterwards. If you update the dependency than it will continue working after Jira 9. With the updated dependency it will throw deprecation warnings on Jira versions [8.4 - 9).
I just discovered that cloud JIRA API is independent from Jira DC/Server API and any clients using it must account for the potential differences: https://community.atlassian.com/t5/Jira-questions/How-can-I-tell-actual-Jira-version-of-a-cloud-instance-for/qaq-p/1483730 According to the cloud Jira API documentation the old |
@pmilosev yes it can get quite tricky. We've compiled a list of the API docs here in case you haven't found it already: |
As well as review comments.
…bs-jira into createmeta-deprecation
for more information, see https://pre-commit.ci
I've updated the code according to the review comments above and accounted for the difference in Jira Cloud API. |
Fixes: DefectDojo#6963 Depends on: pycontribs/jira#1527 If you don't have the update in the mentioned dependency than behaves as it used to - works until Jira 9 and breaks afterwards. If you update the dependency than it will continue working after Jira 9. With the updated dependency it will throw deprecation warnings on Jira versions [8.4 - 9).
* Update gcr.io/cloudsql-docker/gce-proxy Docker tag from 1.33.0 to v1.33.1 (helm/defectdojo/values.yaml) * Refactoring on how jira issue fields are prepared. No change in behaviour (except perhaps in logging). * Added support for the new Jira 9+ createmeta API. Fixes: #6963 Depends on: pycontribs/jira#1527 If you don't have the update in the mentioned dependency than behaves as it used to - works until Jira 9 and breaks afterwards. If you update the dependency than it will continue working after Jira 9. With the updated dependency it will throw deprecation warnings on Jira versions [8.4 - 9). Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@adehad is there something else blocking this PR from being merged ? |
Thanks for the reminder @pmilosev . Could I ask you to see if we can get some test cases in? For testing the versions we don't have access to at the moment I would suggest mocking the value of Let me know if you need a hand with this style of test. Off the top of my head I believe you would want to patch the the test method, as that is probably the best way to patch them before the @mock.patch(...)
def test_createmeta_test_name(): |
Can checks be forced to restart? |
the server CI part is a bit flakey and more failing than passing :s |
I wanted to add some tests but am too busy to do so, sorry. I think tests are indeed a good thing and if anyone is able to write them I would really appreciate it. For me the issue is that I'm not experienced with the stack and writing unit tests would require me to spend a decent amount of time learning. That being said the failing checks predate my changes. I hope the PR can be merged as it is. |
Thank you for your contributions @pmilosev and @dshvedchenko. I've merged it as is for now and raised a separate issue for adding tests. Hopefully can get it into a release soon |
Fix for #1462
This is an alternative to #1503, introducing new API functions and not trying to reconstruct the old API. Even when filtering is used in the old API to get metadata for single project and issue type, the results are still not identical (differ in structure).
I'm not sure if any tests can be written testing against different versions of JIRA. At the moment I have tested manually against JIRA 7.13.8, 8.22.6 and 9.3.1.