Currrently using Webhooks in Jira Server to trigger status change/transition of issues in a specific project. We are migrating to Jira Cloud and our Security policy will not allow us to open the ssl port in our firewall to accept webhook triggers.
This leads me to polling the rest api in a python script to capture the desired projects status changes.
What is the best way to poll for these events, I’m assuming a while loop and some jql like:
project = SUB AND Status CHANGED During (-5, now() )
Welcome to the Atlassian developer community @SimonMarriott,
That JQL seems like a pretty good start. As nit-pick, why not use AFTER -5?
More substantially I do have some questions related to performance and integrity. For performance, scale really matters since you might run into rate limits, which are not simple to calculate as a rate of “requests per second”. I’m thinking about some of the “natural bulk events” like closing a sprint that will look like a batch of individual status changes. For integrity, I can think of some cases where JQL would not return moved or deleted issues as updates. Maybe those edge cases aren’t that important?
Can you tell us a little more about what you are doing with these events? And what are some of the constraints on knowing about them (other than the security of accepting webhooks)?
Hi @ibuchanan,
Thanks for your response, using ‘AFTER -5’ seems a good optimisation for the jql thanks.
We track our code submission process with a python script that checks code reviews, changes in VCS, TeamCity Test project etc. We use a Jira project called submission (SUB) which contains all linked issues found by the python script. We use webhooks to trigger different stages of the python script.
What I am writing is another python script that simulates the jira webhooks, by monitoring submission jira status via the rest api.
I hope this helps clarify what we are doing.
Thanks, that does cover a lot of my concerns.
It sounds like this project is not a usual Jira Software project, which means there wouldn’t be the bulk updates of a sprint closing. And it much reduces integrity problems of moving and/or deleting. In which case, yes, keep it simple with JQL and then reading the issues returned.