Adds jira wrapper API
#31
Conversation
schuylermartin45
commented
Jan 9, 2024
schuylermartin45
commented
- This API manages the API token in the "standard" packaging utils way
- This class follows a singleton design, like the GitHub API wrapper
- Access to the underlying object is restricted through use of a callback. This is intended to help with some future thread-safety goals and to reduce the number of constructions and authorization requests.
- Backports some of the new ideas to the GitHub API wrapper
- Adds unit tests. The GitHub and Jira APIs now have some amount of mocked-out unit testing to back them
- This API manages the API token in the "standard" packaging utils way
- This class follows a singleton design, like the GitHub API wrapper
- Access to the underlying object is restricted through use of a callback.
This is intended to help with some future thread-safety goals and to reduce
the number of constructions and authorization requests.
- Backports some of the new ideas to the GitHub API wrapper
- Adds unit tests. The GitHub and Jira APIs now have some amount of mocked-out
unit testing to back them
schuylermartin45
requested review from
M-Waszkiewicz-Anaconda,
Arishamays1,
gmjen and
JeanChristopheMorinPerso
and removed request for
gmjen
|
|
||
| class JiraApi: | ||
| """ | ||
| Singleton wrapper to the Python Jira project. This "ensures" that we only construct and authenticate the underlying |
There was a problem hiding this comment.
I hate singletons so much as they holding internal object state with itself, have you consider using factory pattern instead ?
They are perceived often as anti pattern, see https://medium.com/aia-sg-techblog/why-singleton-pattern-is-considered-as-anti-design-pattern-c81dd8b7e757
There was a problem hiding this comment.
I guess I was trying to minimize the number of auth calls and object constructions. I think the only state that should remain the same in these APIs is the authorization state, which I think we want for our tools.
Both of these should be making stateless HTTP REST calls under the hood. So I think the Singleton pattern makes a lot of sense here. But let me know if you have specific concerns.
There was a problem hiding this comment.
The problem with singleton can start being apparent when you do tests, you returning JIRA object which would hold its state across different test cases, if you call any stateful method on JIRA object the result could be observer in follow up tests, which could break the 1st rule that the tests should be run independent from each other. The solution for ( if you still want to use singleton ) is to have a wrapper singleton in your test code which would be able to reset the underlying instance each time new test is run
| for this to be able to be called. | ||
| :returns: Authenticated instance of the underlying JIRA API | ||
| """ | ||
| return JiraApi.__jira[0] |
There was a problem hiding this comment.
not thread safe with singleton initialization but probably not mean to be thread safe
There was a problem hiding this comment.
JC and I briefly talked about this. My initial callback mechanism I just redacted could have leant itself to being more thread safe. That being said, it's unclear (from the small amount of research I've done) if the underlying JIRA API or the GitHub API are threadsafe anyways.
