mudlet/.github/scripts/resolve-milestone.sh
Vadim Peretokin a099a20aee
infrastructure: fix milestone assignment, unbreak the key sequence tests (#9679)
#### Brief overview of PR changes/additions

- `add-milestone` resolves the milestone by exact title first and then
by version prefix, so `5.0.0` finds `5.0.0 next release` again, and
fails loudly instead of assigning nothing. 191 PRs merged since 4.22.0
have no milestone.
- `TKeySequenceEditTest`'s two focus traversal cases no longer fail
under a bare Xvfb: ctest pins the offscreen platform on X11, and a
direct run without a window manager skips with a message instead of
burning the activation timeout twice.

#### Motivation for adding to Mudlet

Both were failing silently. The milestone step matched a title that no
longer exists and exited 0; and the traversal tests were the one red
mark in an otherwise green local suite, which everybody had to re-derive
as environmental.

The milestone lookup is now a script under `.github/scripts/`, covered
by a new `MilestoneResolutionTest` that runs it against a stubbed `gh`.
Re-introducing the original bug makes that test fail.

Worth knowing: `add-milestone` on this PR still assigned nothing,
because `pull_request_target` runs the copy of the workflow that is on
the base branch. It takes effect for pull requests opened after this
merges.

#### Other info (issues closed, discussion etc)

- Closes #9671 - CI: add-milestone silently assigns nothing - metadata
says "4.23.0" but the milestone is titled "4.23.0 next release"
- Closes #9575 - TKeySequenceEditTest: two traversal tests fail under
bare Xvfb (no window manager)

Test case: `ctest -R 'MilestoneResolutionTest|TKeySequenceEditTest'`,
plus `xvfb-run --auto-servernum ctest -R TKeySequenceEditTest` for the
case #9575 is about.

Assisted-by: Claude:claude-opus-5
2026-08-06 06:07:10 +02:00

50 lines
2 KiB
Bash
Executable file

#!/usr/bin/env bash
#
# Turns the version in .github/repo-metadata.yml into the number of the matching
# open milestone, and prints "<number> <title>".
#
# Milestone titles carry a suffix in practice - "4.23.0 next release" for a
# metadata value of "4.23.0" - so the exact-title match this replaces found
# nothing, set an empty number, and exited 0, leaving every pull request in the
# repository unassigned without ever failing (#9671). Anything short of exactly
# one match is now an error, so a renamed milestone cannot go unnoticed again.
#
# Diagnostics go to stderr, because stdout is this script's answer.
#
# Inputs, all from the environment:
# REPO owner/name of the repository (required)
# NEXT_MILESTONE version to look for (required)
# GH_TOKEN token for the gh call
set -euo pipefail
: "${REPO:?REPO must be set}"
: "${NEXT_MILESTONE:?NEXT_MILESTONE must be set}"
if ! milestones=$(gh api "repos/${REPO}/milestones?state=open&per_page=100"); then
echo "::error::Could not read the open milestones of ${REPO}" >&2
exit 1
fi
# An exact title wins outright; otherwise the version has to be the leading word
# of exactly one title, so a genuinely ambiguous set is refused rather than
# guessed at
matches=$(jq -c --arg wanted "${NEXT_MILESTONE}" '[.[] | select(.title == $wanted)]' <<< "${milestones}")
if [ "$(jq 'length' <<< "${matches}")" -eq 0 ]; then
matches=$(jq -c --arg wanted "${NEXT_MILESTONE}" \
'[.[] | select(.title | startswith($wanted + " "))]' <<< "${milestones}")
fi
match_count=$(jq 'length' <<< "${matches}")
if [ "${match_count}" -eq 0 ]; then
echo "::error::No open milestone matches '${NEXT_MILESTONE}' from .github/repo-metadata.yml. Open milestones: $(jq -r '[.[].title] | join(", ")' <<< "${milestones}")" >&2
exit 1
fi
if [ "${match_count}" -gt 1 ]; then
echo "::error::'${NEXT_MILESTONE}' matches several open milestones, so which one to use is not clear: $(jq -r '[.[].title] | join(", ")' <<< "${matches}")" >&2
exit 1
fi
jq -r '"\(.[0].number) \(.[0].title)"' <<< "${matches}"