Update JIRA ticket with status on merge

[srl295]

@sffc this is somewhat of a question.

• Does the pr-check get notified when a PR is merged?

Context: https://unicode-org.atlassian.net/browse/CLDR-15400

There's sometimes confusion when a PR or commit mentions a JIRA ticket but isn't targetted at that ticket. xrefs are super helpful, but can add noise. (I filed this ticket to try to avoid needing some kind of policy that restricts mentioning other tickets.)

Jira's "developer" field isn't really a field, you can't really search for "Tickets that have commits" and even if you could, you don't know if the ticket was really fixed by the PR or just mentioned by it.

If pr-check gets notified on merge, then it could actually update a Jira field, something like "mergedIn".

• For branch maint/maint-43 it could definitely add maint-43 to mergedIn.
• For branch main it could add main to mergedIn

More advanced:

• We could somehow use the current version logic to actually use the "targeted release version" for that branch for the mergedIn field.
• mergedIn should be a list, not a singleton, because of cherry picks.

[sffc]

I'd make the hook be "commits on main" or "commits on a branch matching maint/.*" and if you want it to use the bot account to update Jira I think that's fine.

[srl295]

I'd make the hook be "commits on main" or "commits on a branch matching maint/.*" and if you want it to use the bot account to update Jira I think that's fine.

Does/could this pr check accept such a hook?

I'm asking about the mechanism… are you suggesting this be implemented as a new github action on push to main?

[sffc]

The cloud function already routes webhook requests; this can be added as an additional webhook that gets processed.

https://github.com/unicode-org/jira-github-pr-check/blob/main/app.js#L394

[srl295]

Actually, it would also be helpful to update a field whenever a PR that targets that ticket is opened. So whenever a PR titled CLDR-12345 do the stuff is opened, it adds the URL to that PR to the list of PR links in a new field. yes, it would have excess content if something was misticketted. but it would allow searching on which tickets ever had a PR opened against them. As mentioned above:

• the 'developer' section in Jira that shows PRs includes mentioned but not targetting PRs (See also CLDR-54321)
• the developer section isn't a real field (probably client-side) and can't be searched against.

[srl295]

per CLDR-TC:

• add a label maint to PRs that are on any maint/* branch