Repository navigation
BUG: the changelog workflow stopped running, and CHANGELOG.md is 37 merged pull requests behind #1173
Description
Activity
I reproduced both causes and took the backfill, which is #1180. Two notes on the diagnosis.
Neither trigger can fire, not just the new one
The report has the
pull_request_targethalf. The other half is worth stating because it rules out a fallback:masterstill declarespull_request, and that does not fire either.$ git show upstream/master:.github/workflows/changelog.yml | head -6 name: Populate Changelog on: pull_request: types: [closed] branches: - developA
pull_requestworkflow is read from the pull request's own branch, and apull_request_targetone from the default branch. So:- a
pull_requestevent reads the file from the branch being merged, which carriesdevelop's copy, and that declares onlypull_request_target; - a
pull_request_targetevent reads the file frommaster, which declares onlypull_request.
Each event finds the version that does not declare it. That is why nothing has run rather than something running and failing, and it is also why this cannot be fixed from a pull request into
develop—masterhas to carry thepull_request_targetversion before the trigger exists at all.The run history agrees
2026-08-14T00:12 pull_request failure BUG: seed parachute pressure noise with per-instan 2026-08-14T00:05 pull_request failure CI: keep per-matrix coverage artifacts and fail Co 2026-08-13T23:59 pull_request failure ENH: Add tube-fin aerodynamic surface 2026-08-13T13:15 pull_request failure BUG: Restore UTC fallback without timezonefinder 2026-08-12T22:27 pull_request success ENH: StochasticFreeFormFins for Monte Carlo simulaLast run 2026-08-14T00:12; #1112 merged at 2026-08-14T09:44. Every recorded run is
event=pull_request, so the newer trigger has never fired, and the four failures before it are theRELEASE_TOKENproblem rather than anything to do with the trigger.What #1180 covers and what it does not
It writes the 32 entries that belong in
[Unreleased], fromgit log 5eae273b..develop, leaving out the sevenTST:commits per the file's own header. It does not touch the workflow, so the next merge falls out of the file again.The two remaining pieces both need someone with repository access: putting the
pull_request_targetversion onmaster, and whatever happened toRELEASE_TOKEN. If the team would rather not wait for the next release to syncmaster, a trigger that does not depend on the default branch would also work —on: push: branches: [develop]is read from the pushed branch and has secrets — but that changes how the job identifies the merged pull request, so it is a design call rather than a patch, and I did not want to fold it into a changelog backfill.- a
- added a commit that references this issue
on Aug 19, 2026 - linked a pull request that will close this issueDOC: backfill the Unreleased changelog entries the automation missed #1180
on Aug 19, 2026
The last commit to
CHANGELOG.mdis5eae273b, on 12 August. Thirty-seven pull requests have been merged intodevelopsince then and none of them is recorded, so the[Unreleased]section no longer describes what is on the branch. The highest pull request it mentions is #1140.Two things went wrong, one after the other, and both need fixing before entries start appearing again.
The workflow has not been triggered since #1112
#1112 changed the trigger from
pull_requesttopull_request_target, so the job would run for pull requests from forks, and merged at2026-08-14T09:44:01Z. Nothing has run since.The next merge after #1112 was #1149 at
2026-08-14T09:45:03Z, and thirty more have landed since. The workflow is stillactive, so it has not been disabled.Where GitHub reads the file from looks like the reason. The documentation says a
pull_request_targetworkflow is taken from the default branch rather than from the pull request's base branch. This repository's default branch ismaster, which is 77 commits behinddevelopand still carries the olderchangelog.ymlwith thepull_requesttrigger. Thepull_request_targetversion exists only ondevelop, where nothing reads it..github/workflows/pr_agent.ymlsits the same way:pull_request_target, present only ondevelop, last run2026-08-12T02:44:27Z. Every recorded run of both workflows reportsevent=pull_request, which fits neither having fired under the newer trigger.I cannot see the repository's Actions settings, so there may be something here that is only visible from the inside.
RELEASE_TOKENwas already empty before thatThe four runs before #1112 did fire, and all four died on the first step:
That step is
actions/checkoutwithtoken: ${{ secrets.RELEASE_TOKEN }}, so the secret is resolving to nothing. The last run that got past it was2026-08-12T22:27:08Z, which puts the change somewhere between then and2026-08-13T13:15:27Z.This one will still be waiting once the trigger works again, so it is worth checking the secret at the same time rather than after another round of silent failures.
To reproduce
For the token, the failing step's log is in run
31756544967, job94633386642.Expected behavior
A pull request merged into
developadds its entry to the[Unreleased]section ofCHANGELOG.md, which is what the pull request template promises contributors when it tells them the file needs no action from them.Additional context
#1101 is the fork problem #1112 set out to solve, and #905 is where the automation came from, so neither of those covers this.
Whatever the fix turns out to be, the thirty-seven entries from the gap will not appear on their own. It may be easier to write them in one pass from the merge list than to try to replay the workflow over each pull request.