mirror of
https://github.com/Mudlet/Mudlet
synced 2026-08-13 18:26:27 -04:00
#### 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
50 lines
2 KiB
Bash
Executable file
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}"
|