Create Release Plan Pick List workflow

[Copilot]

Adds a workflow_dispatch workflow that automates generating the cherry-pick list for release plan issues, eliminating the manual effort of collecting and ordering PRs from a release project.

Changes

• New workflow .github/workflows/release-plan-pick-list.yml
  • Inputs: project_number (az-digital org GitHub Projects v2) and issue_number (az-digital/az_quickstart release plan issue)
  • Pages through all project items via GraphQL, filtering to PRs from az-digital/az_quickstart in the Done status column
  • Warns and skips PRs with no merge commit (rebase-merged PRs)
  • Sorts PRs by mergeCommit.committedDate (oldest → newest; ISO 8601 sorts lexicographically)
  • Posts a comment to the release plan issue containing:
    • ## Pull Requests (in commit order from oldest to newest) — - #<number> list
    • ## Pick List — combined git cherry-pick -x <sha1> <sha2> ... command, plus a second block with one command per commit

Example comment output:

## Pull Requests (in commit order from oldest to newest)

- #1042
- #1055
- #1061

## Pick List

git cherry-pick -x a1b2c3d e4f5a6b 7c8d9e0

git cherry-pick -x a1b2c3d
git cherry-pick -x e4f5a6b
git cherry-pick -x 7c8d9e0

Uses REPO_DISPATCH_TOKEN (PAT with read:project org scope) as GH_TOKEN. Sets permissions: {} on the job to restrict the implicit GITHUB_TOKEN.

Related issues

How to test

Trigger the workflow manually from the Actions tab with a valid az-digital project number and an az-digital/az_quickstart issue number. Verify the generated comment on the issue matches the PRs in the Done column of the project, ordered by commit date, with correct cherry-pick SHAs.

Types of changes

Arizona Quickstart (install profile, custom modules, custom theme)

• Patch release changes
  • Bug fix
  • Accessibility, performance, or security improvement
  • Critical institutional link or brand change
  • Adding experimental module
  • Update experimental module
• Minor release changes
  • New feature
  • Breaking or visual change to existing behavior
  • Upgrade experimental module to stable
  • Enable existing module by default or database update
  • Non-critical brand change
  • New internal API or API improvement with backwards compatibility
  • Risky or disruptive cleanup to comply with coding standards
  • High-risk or disruptive change (requires upgrade path, risks regression, etc.)
• Other or unknown
  • Other or unknown

Drupal core

• Patch release changes
  • Security update
  • Patch level release (non-security bug-fix release)
  • Patch removal that's no longer necessary
• Minor release changes
  • Major or minor level update
• Other or unknown
  • Other or unknown

Drupal contrib projects

• Patch release changes
  • Security update
  • Patch or minor level update
  • Add new module
  • Patch removal that's no longer necessary
• Minor release changes
  • Major level update
• Other or unknown
  • Other or unknown

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My change requires release notes.