[PP-3687] Add JIRA version creation automation github workflow.

[dbernstein]

Description

This PR adds an AI generated workflow that will create a release page JIRA by grabbing the github release version, extracting all the JIRA ticket IDs from the release's body, associating those tickets with the release in JIRA, and updating the fixVersions property of each ticket with the release.

One caveat. It looks like the script will try to associate any PP-* issue key found in the github release notes, regardless of whether the issue is actually in the release. For example, if the release notes contain a reference to another ticket, the script will include that ticket in the JIRA release. I believe one ticket can be associated with multiple releases so it's not a technical issue per say. But there is the potential for muddying the waters. So we have to be careful to remove any secondary JIRA references in the release notes.

Motivation and Context

https://ebce-lyrasis.atlassian.net/browse/PP-3687

How Has This Been Tested?

This has been tested.

I pushed a tag associated with this PR. Then published an unofficial release with PP-3687 in the body. You can see the results here: https://ebce-lyrasis.atlassian.net/projects/PP/versions/12159/tab/release-report-all-issues

Checklist

• I have updated the documentation accordingly.
• All new and existing tests passed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.18%. Comparing base (22d454e) to head (aca9836).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3058   +/-   ##
=======================================
  Coverage   93.18%   93.18%           
=======================================
  Files         489      489           
  Lines       44943    44943           
  Branches     6191     6191           
=======================================
  Hits        41880    41880           
  Misses       1986     1986           
  Partials     1077     1077           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jonathangreen]

Looks good, added a couple comments

[jonathangreen]

None of the curl calls check for failure. If the "Create New Jira Release" step fails (e.g., duplicate version name, auth failure), subsequent steps will still run and silently fail or produce confusing results.

Suggestions:

• Add --fail or --fail-with-body to all curl commands so non-2xx responses cause the step to fail.
• Alternatively, capture the response, check the HTTP status code, and fail explicitly.

[jonathangreen]

Is this step needed? It doesn't appear any of the following steps use it and when I go to https://github.com/atlassian/gajira-login it says:

⚠️ This repository is no longer maintained and all Gajira actions have been deprecated.

[jonathangreen]

This step is intended to no-op when release notes contain no PP- keys, but I think run steps execute with bash -e -o pipefail, so grep -oE "${JIRA_PROJECT_KEY}-[0-9]+" returns exit code 1 and aborts before the if [ -z "$KEYS" ] check runs. Worth checking on this anyway.

[jonathangreen]

Line 58 directly interpolates github.event.release.body into a shell command:

KEYS=$(echo "${{ github.event.release.body }}" | grep -oE "PP-[0-9]+" | sort -u)

The release body is user-controlled input. If it contains shell metacharacters (e.g., "; rm -rf /; "), they will be executed. This is a well-known https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#understanding-the-risk-of-script-injections vulnerability.

I don't think the security risk here is high, since we are controlling releases. If an attacker is creating a release we have big problems already, but I do think its worth addressing so that shell characters don't accidentally break this workflow. This is the fix suggested by the docs:

  env:
    RELEASE_BODY: ${{ github.event.release.body }}
  run: |
    KEYS=$(echo "$RELEASE_BODY" | grep -oE "PP-[0-9]+" | sort -u)

[jonathangreen]

Minor: Instead of creating the version in the "Create New Jira Release" step, and then immediately querying for it. It looks like the rest/api/3/version response contains the ID already. Can we just parse it in that step and pass it to this step? I think that would save us bugs around looking up the release name with JQ.

[jonathangreen]

One other thing we might want to do here is turn this into an action like the poetry action:
https://github.com/ThePalaceProject/circulation/tree/main/.github/actions/poetry

@dwilcox mentioned in the sprint planning today that he would like to have this run in our other repos, so it might be nice to have it as an action rather then copy paste this YAML file everywhere.