BUG: the changelog workflow stopped running, and CHANGELOG.md is 37 merged pull requests behind

[thc1006]

The last commit to CHANGELOG.md is 5eae273b, on 12 August. Thirty-seven pull requests have been merged into develop since 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_request to pull_request_target, so the job would run for pull requests from forks, and merged at 2026-08-14T09:44:01Z. Nothing has run since.

2026-08-14T00:12:03Z  failure
2026-08-14T00:05:22Z  failure
2026-08-13T23:59:03Z  failure
2026-08-13T13:15:27Z  failure
2026-08-12T22:27:08Z  success

The next merge after #1112 was #1149 at 2026-08-14T09:45:03Z, and thirty more have landed since. The workflow is still active, so it has not been disabled.

Where GitHub reads the file from looks like the reason. The documentation says a pull_request_target workflow is taken from the default branch rather than from the pull request's base branch. This repository's default branch is master, which is 77 commits behind develop and still carries the older changelog.yml with the pull_request trigger. The pull_request_target version exists only on develop, where nothing reads it.

.github/workflows/pr_agent.yml sits the same way: pull_request_target, present only on develop, last run 2026-08-12T02:44:27Z. Every recorded run of both workflows reports event=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_TOKEN was already empty before that

The four runs before #1112 did fire, and all four died on the first step:

##[error]Input required and not supplied: token

That step is actions/checkout with token: ${{ secrets.RELEASE_TOKEN }}, so the secret is resolving to nothing. The last run that got past it was 2026-08-12T22:27:08Z, which puts the change somewhere between then and 2026-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

gh api repos/RocketPy-Team/RocketPy/actions/workflows \
  --jq '.workflows[] | select(.name=="Populate Changelog") | .id'

gh api "repos/RocketPy-Team/RocketPy/actions/workflows/<id>/runs?per_page=10" \
  --jq '.workflow_runs[] | "\(.created_at) \(.conclusion // .status) event=\(.event)"'

For the token, the failing step's log is in run 31756544967, job 94633386642.

Expected behavior

A pull request merged into develop adds its entry to the [Unreleased] section of CHANGELOG.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.

[ting-hong-shieh]

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_target half. The other half is worth stating because it rules out a fallback: master still declares pull_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:
      - develop

A pull_request workflow is read from the pull request's own branch, and a pull_request_target one from the default branch. So:

• a pull_request event reads the file from the branch being merged, which carries develop's copy, and that declares only pull_request_target;
• a pull_request_target event reads the file from master, which declares only pull_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 — master has to carry the pull_request_target version 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 simula

Last 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 the RELEASE_TOKEN problem 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], from git log 5eae273b..develop, leaving out the seven TST: 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_target version on master, and whatever happened to RELEASE_TOKEN. If the team would rather not wait for the next release to sync master, 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.