[janhoy]

Description

Check changelog entry fails with gh: Not Found (HTTP 404) whenever an entry filename contains #, which is our own PR#<n>- / GITHUB#<n>- convention. The path is interpolated straight into a contents URL, so # is read as a fragment delimiter and the request truncates to the directory.

Open PRs hitting this:

• Per-version docs styling and unified javadocs search #5049 — PR#5049-docs-site-styling.yml, currently red
• Solr Cell: index Tika 4.x tk:chunks into a dense_vector field #4863 — PR#4853-update-org-apache-tika-tika-core.yml
• Tolerate JVM warning lines when detecting Java version #4765 — PR#4765-improve-java-version-parsing.yml

The latter two last ran the check before the raw-fetch step landed in #5099, so they fail on their next push rather than right now.

Solution

Fetch each entry by the contents_url already returned in the pulls/{n}/files listing. It is URL-encoded and pinned to the head commit, so nothing PR-authored goes into the URL, every other character needing escaping is covered too, and HEAD_SHA is no longer needed. The loop rejects any URL that is not a contents URL for this repository, since gh api sends the job's token to whatever host it is given.

Tests

Ran both workflow steps verbatim against the three PRs above. Each # entry 404s on the old URL and fetches on the new one; validate-changelog-yaml.py then exits 0. Also checked that a PR with no entry still short-circuits, that an ordinary SOLR-… filename is unaffected, and that the URL guard rejects a foreign host. bash -n passes on both run blocks.

No changelog entry, matching the previous fixes to this workflow (#5099, #4941).

---

AI Assisted: written with Claude Code, reviewed and tested by me.

[github-actions]

Automated PR triage (LLM-generated; may be wrong). Checked once, when the PR was opened or marked ready; not updated on later pushes.

No clear mismatches in the answered judgements.

	Warranted?	In PR?	Confidence	Why
✅ Jira issue in title	no	no	high	The change is a fix to the GitHub Actions workflow (.​github/​workflows/​validate-changelog.​yml) which is internal CI tooling, not a user-facing feature or bug fix in the Solr server itself.​
✅ Changelog	(not-worthy)	no entry	high	This is a build/​CI change fixing the changelog validation workflow, which does not warrant a release note for Solr users or operators.​
✅ Reference Guide update	no	no	high	The change modifies an internal GitHub Actions workflow and does not affect any user-facing configuration, API, or behavior documented in the Reference Guide.​
✅ Upgrade notes	no	no	high	The change is internal to the CI pipeline and has no impact on Solr deployments or upgrades.​
✅ Tests	no	no	high	The change is to a GitHub Actions workflow (CI/​developer tooling), which does not require unit tests according to the guidelines.​

⚠️ mismatch, ❔ uncertain or unanswered, ✅ agrees. Matching changelog, docs and test files were hidden from the model; the PR description may still mention them. File presence does not establish adequacy. Assessed commit 1f89be02d2b3a225532ac4a58afb764666de1015.

[Copilot]

🟢 Approval recommended

There are no active review issues for the changelog validation update supporting filenames containing #.

No open issues 🎉

What changed in this PR

Fixes changelog validation for entry filenames containing #, including the repository’s PR#<n>- and GITHUB#<n>- conventions.

Changes:

• Fetches entries using GitHub’s URL-encoded, commit-pinned contents_url instead of constructing URLs from filenames.
• Rejects URLs outside this repository’s GitHub contents endpoint and removes the unused HEAD_SHA variable.

File	Description
.github/​workflows/​validate-changelog.yml	Carries contents URLs through entry selection and validates them before fetching changelog files.

_{Review effort: Balanced}