We have integrated Github and Jira, and are able to see the execution of the Github action deployed to the QA environment in the "Deployments" Tab within the issue.
Therefore, we use Jira Automation to send a web request notification to Teams app when Jira Automation triggers "Deployment successful" event, the notification message includes the corresponding issue information.
After setting up this automation rule, notifications are sent, included issue information. However, some issues receive duplicate notifications. Thus, we would like to know how to configure the rule conditions to ensure that "issues included in the same deployment only send one notification."
In our Github repository, the ways we connected with Jira is as follows:
For example, I open a PR with information below:
1. branch name `JRA-123`
2. PR title `JRA-123: Fix some bugs`
3. PR description: `https://jra.atlassian.net/browse/JRA-123`
Once I merge the PR into develop, develop branch will have a commit `merge Pull Request #1 from JRA-123`, then I manually trigger github action to deploy develop branch to testing environment.
When deployment successfully, Jira Automation will send notification for issue `JRA-123` twice, which I expect to send only once.
I'd like to know whether we add too many issue keys information in a single PR which leads Jira to trigger multiple "deployment successfully" events for the same ticket in a single deployment. Thank you.
Hi @Maureen Wang , welcome to the Atlassian Community
A solution to your query would be to have a custom field in Jira that holds the status of the deployment for a certain issue. Check for non-deployed prior to sending the notification. If it already was deployed, then withhold sending the notification.
Hope this helps you in keeping notifications and deployments in check,
Dick
By voting for helpful posts and marking answers to your question, you're helping people with similar questions find a solution more quickly. Sharing is caring applies to knowledge as well :)
Thank you for the suggestion!
Since in our case, an issue may be deployed to the QA environment multiple times, we need to ensure that a notification is sent after each successful deployment, which makes updating the status not the most suitable approach.
I found that multiple notifications were sent because, in the same deployment, three jobs are run, and the deployment URL is sent with each job, so there can be up to three notifications. To solve this, I decided to create a custom field to store the part of the GitHub deployment URL before /job
. If the issue already contains this URL, the notification won't be sent again.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm glad you even managed to put very useful information in the custom field. Even better than the status I suggested!
Glad this was useful. Let's tell it to the world by marking the answer!
Dick
By voting for helpful posts and marking answers to your question, you're helping people with similar questions find a solution more quickly. Sharing is caring applies to knowledge as well :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.