Adjust sensor to better support large jira projects #46
Conversation
floatingstatic
force-pushed
the
sensor-improvements
branch
from
2751c86 to
35e815d
Compare
floatingstatic
force-pushed
the
sensor-improvements
branch
from
35e815d to
e2e9c30
Compare
|
Hi Eugen (@armab) I wonder if I could bump this PR which addresses #45. Currently I have to use a forked version of this pack due to the size of some Jira projects in my org. The way the sensor currently works as I understand it is we load all issues in a jira project into the sensor object under If you are not the current maintainer of this pack perhaps you could pull in that person to help review this change? I'm also happy to help support this pack as I do for |
There was a problem hiding this comment.
Great stuff! 💯
JIRA is known to be used with lots of data/issues and manytimes things are slow.
This one is very helpful, thanks for the contribution!
Happy to add you as a maintainer @floatingstatic for this pack.
Could you please open a PR similar to this https://github.com/StackStorm-Exchange/stackstorm-napalm/pull/68/files in this repo to list yourself as a jira pack maintainer?
| all_issues = self._jira_client.search_issues(self._jql_query, maxResults=None) | ||
| self._issues_in_project = {issue.key: issue for issue in all_issues} | ||
|
|
||
| self._jql_query = 'project={} ORDER BY id DESC'.format(self._project) |
There was a problem hiding this comment.
Another addition would be storing the latest ID in the st2 K/V so if the sensor is restarted it will remember where it stopped last time.
https://docs.stackstorm.com/sensors.html#datastore-management-operations
Many pack Sensors are implemented this way, would it make sense for JIRA too? Maybe in the next PR, if you want to implement that?
|
Hi @armab yeah i think using the kv store makes sense and I'm happy to add that feature in another PR (will open an issue to track this) |
|
Opened #51 for maintainer |
Addresses issue described in #45
Fixes #45