[RFC] Provide more automatic Jira integration about peril-settings HOT 5 CLOSED

Cool! I really like this idea. A few pieces of feedback:

• It might be wise to have a permissive format for commit messages – some teams use the "[Push Notifications] Fixes whatever..." format, for example. We could use that format for Jira tickets.
• GitHub uses visual design to show when something like "fixes #123" in a PR body will close an issue. We might want Peril to comment on the PR with a message like "Merging this PR will move PLATFORM-89 to Review column", with PLATFORM-89 turned into a link to that ticket.
• Different teams use different columns in Jira, so our implementation might have to handle moving to different columns based on which project the ticket is in.

from peril-settings.

It might be wise to have a permissive format for commit message

It's totally permissive, there's no attempt at forcing a format - I think [PLAT-123] did a thing would not pass the regex though. Could add an extra regex for that too.

GitHub uses visual design to show when something like "fixes #123" ...

We could have a "Synced with Jira" label, that means less Peril noise and easy to know that it's happening.

Different teams use different columns in Jira

Great, will convert the check into an includes in an array instead of string matching 👍

from peril-settings.

It's totally permissive, there's no attempt at forcing a format - I think [PLAT-123] did a thing would not pass the regex though. Could add an extra regex for that too.

Added a test for this, it was supported already 👍

from peril-settings.

Does the current iteration of our automated Jira sync handle tickets with multiple associated PRs? For example, I have a Jira ticket for upgrading the version of rack used across a number of projects. I've been linking back to the same Jira ticket from each PR.

Should I be using multiple Jira tickets for this case?

from peril-settings.

Sub-tasks maybe? Or we can figure a way to make the message not indicate that it should close the ticket. It's very malleable, and the aim is to map to existing behavior, not necessarily define it if possible.

from peril-settings.