feat(changelog): adopt changelog-action with EN/ES/ZH changelogs #56

Merged
rcsheets merged 3 commits from feat/changelog-action into main 2026-07-26 08:40:26 +00:00
Owner

Adds the shared brooktrails/changelog-action (pinned @v1) to gllm's release pipeline and configures three parallel changelogs: English, Spanish, and Mandarin Chinese. gllm releases several times a day and had no changelog at all; from the next release on, each one is summarized and committed back automatically.

Changes

  • .forgejo/workflows/build-push.yaml — new uses: step after Push git tag, with a 3-language targets: list. Each target gets its own summary in its own language, all committed together with [skip ci]; a changelog failure only warns, never fails the release.
  • .changelog.env (new) — gllm's product identity, the single source of truth the action reads to build the prompt.
  • CHANGELOG.md, CHANGELOG.es.md, CHANGELOG.zh.md (new) — full structure for all 42 existing versions: header + one section per version + compare-link block.

Backfill in progress

This PR ships every entry as a STUB: N bytes of changes. placeholder so the structure (and CI splicing) works immediately. I'm backfilling the stubs into real, per-language summaries against the inference service in the background — 42 versions × 3 languages — and will push the filled prose onto this branch as it completes (the tooling only ever rewrites stubs, so it's re-runnable and won't touch anything already filled). Best reviewed once backfill finishes; I'll comment when it's done.

Notes

  • Depends on brooktrails/changelog-action@v1 (already published; same action slp and bliis use).
  • Compare/tag links and the section scaffold match exactly what the action expects, so new releases splice cleanly above [0.28.2].

🤖 Generated with Claude Code

Adds the shared **`brooktrails/changelog-action`** (pinned `@v1`) to gllm's release pipeline and configures **three parallel changelogs**: English, Spanish, and Mandarin Chinese. gllm releases several times a day and had no changelog at all; from the next release on, each one is summarized and committed back automatically. ## Changes - **`.forgejo/workflows/build-push.yaml`** — new `uses:` step after *Push git tag*, with a 3-language `targets:` list. Each target gets its own summary in its own language, all committed together with `[skip ci]`; a changelog failure only warns, never fails the release. - **`.changelog.env`** (new) — gllm's product identity, the single source of truth the action reads to build the prompt. - **`CHANGELOG.md`, `CHANGELOG.es.md`, `CHANGELOG.zh.md`** (new) — full structure for all 42 existing versions: header + one section per version + compare-link block. ## Backfill in progress This PR ships every entry as a `STUB: N bytes of changes.` placeholder so the structure (and CI splicing) works immediately. I'm backfilling the stubs into real, per-language summaries against the inference service in the background — 42 versions × 3 languages — and will push the filled prose onto this branch as it completes (the tooling only ever rewrites stubs, so it's re-runnable and won't touch anything already filled). **Best reviewed once backfill finishes**; I'll comment when it's done. ## Notes - Depends on `brooktrails/changelog-action@v1` (already published; same action slp and bliis use). - Compare/tag links and the section scaffold match exactly what the action expects, so new releases splice cleanly above `[0.28.2]`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
feat(changelog): adopt changelog-action with EN/ES/ZH changelogs
All checks were successful
ci / test_and_build (pull_request) Successful in 22s
79b4f6ce54
gllm releases several times a day and had no CHANGELOG. Wire the shared
brooktrails/changelog-action (pinned @v1) into build-push so every release is
summarized and committed back automatically, in three parallel languages:

- CHANGELOG.md    (US English)
- CHANGELOG.es.md (Spanish)
- CHANGELOG.zh.md (Mandarin Chinese)

This commit ships the full structure: a header plus one section per existing
version (42 of them) and the compare-link block, with each body a
"STUB: N bytes of changes." placeholder. The stubs are being backfilled into
real summaries via the action's backfill tooling; the STUB lines are obvious
wherever they land until then, and the section/link scaffold is exactly what
the CI action splices new releases above.

Product identity lives in .changelog.env; the prompt and tooling live in the
action, shared with slp and bliis so they cannot drift apart.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Collaborator

Automated review by pr-reviewer v0.39.0 | Safety Check | Claude Sonnet 5 | tracking id r-62ae6c-9a51b5
This is an AI-generated review and may contain mistakes.

Status: Completed


⚠️ The primary review (Mistral Small) failed because the diff is too large for that model. The review below is from Claude Sonnet 5, which reviewed the same diff.

Verdict: LGTM — The "secret detected" flag is a false positive from standard ${{ secrets.FORGEJO_TOKEN }} Actions syntax, not an actual leaked credential; the rest of the diff is new changelog scaffolding and a benign CI step with safe failure handling.

Reviewed the diff carefully, focusing on the flagged automated observation ("possible secret or credential detected").

  • The workflow change references token: ${{ secrets.FORGEJO_TOKEN }} and inference-url: ${{ vars.INFERENCE_URL }} — these are standard Forgejo/GitHub Actions secret/variable references, not literal exposed credentials. This is almost certainly what tripped the automated secret scanner (the string "secrets." / "token:"), but it's the normal, safe pattern for consuming secrets in CI, not a leak.
  • The action is pinned to @v1 from a private/internal registry (git.brooktrails.org/brooktrails/changelog-action@v1), consistent with other repos per the PR description.
  • Changelog failure is designed to only warn, not fail the release build — reasonable, low-risk design given release cadence.
  • New files are just markdown changelogs (stub placeholders) and a .env-style config file with product description strings, no actual secrets or keys in .changelog.env.
  • No changes to core build/push/deploy logic — the new step is inserted after tag push and before the CUDA canary build, doesn't appear to alter existing steps.
  • No large binaries, no obviously bad logic in the YAML.

Nothing here indicates an actual leaked secret, credential, or dangerous logic change. The flagged pattern is a false positive from referencing secrets.FORGEJO_TOKEN via standard Action syntax.

*Automated review by [pr-reviewer](https://git.brooktrails.org/brooktrails/pr-reviewer) v0.39.0 | Safety Check | Claude Sonnet 5 | tracking id `r-62ae6c-9a51b5`* *This is an AI-generated review and may contain mistakes.* **Status:** ✅ Completed --- > ⚠️ The primary review (**Mistral Small**) failed because the diff is too large for that model. The review below is from **Claude Sonnet 5**, which reviewed the same diff. **✅ Verdict: LGTM** — The "secret detected" flag is a false positive from standard `${{ secrets.FORGEJO_TOKEN }}` Actions syntax, not an actual leaked credential; the rest of the diff is new changelog scaffolding and a benign CI step with safe failure handling. Reviewed the diff carefully, focusing on the flagged automated observation ("possible secret or credential detected"). - The workflow change references `token: ${{ secrets.FORGEJO_TOKEN }}` and `inference-url: ${{ vars.INFERENCE_URL }}` — these are standard Forgejo/GitHub Actions secret/variable references, not literal exposed credentials. This is almost certainly what tripped the automated secret scanner (the string "secrets." / "token:"), but it's the normal, safe pattern for consuming secrets in CI, not a leak. - The action is pinned to `@v1` from a private/internal registry (`git.brooktrails.org/brooktrails/changelog-action@v1`), consistent with other repos per the PR description. - Changelog failure is designed to only warn, not fail the release build — reasonable, low-risk design given release cadence. - New files are just markdown changelogs (stub placeholders) and a `.env`-style config file with product description strings, no actual secrets or keys in `.changelog.env`. - No changes to core build/push/deploy logic — the new step is inserted after tag push and before the CUDA canary build, doesn't appear to alter existing steps. - No large binaries, no obviously bad logic in the YAML. Nothing here indicates an actual leaked secret, credential, or dangerous logic change. The flagged pattern is a false positive from referencing `secrets.FORGEJO_TOKEN` via standard Action syntax.
rcsheets force-pushed feat/changelog-action from 79b4f6ce54
All checks were successful
ci / test_and_build (pull_request) Successful in 22s
to 9e5a09267e
All checks were successful
ci / test_and_build (pull_request) Successful in 23s
2026-07-25 09:45:13 +00:00
Compare
Collaborator

Automated review by pr-reviewer v0.41.0 | Safety Check | Claude Sonnet 5 | tracking id r-6485aa-e9f289
This is an AI-generated review and may contain mistakes.

Status: Completed


⚠️ The primary review (Mistral Small) failed. The review below is from Claude Sonnet 5, which reviewed the same diff.

Verdict: LGTM — No real secrets or breaking changes present; the flagged "secret" is just a normal secrets.FORGEJO_TOKEN reference, and the rest is additive stub/config content.

Reviewed the diff carefully. The automated "possible secret" flag is a false positive: the workflow only references secrets.FORGEJO_TOKEN and vars.INFERENCE_URL via standard Forgejo Actions expression syntax — no literal credentials are embedded. This is the normal, correct way to pass secrets into a CI step.

The rest of the change is low-risk:

  • New .changelog.env contains only non-sensitive product metadata (name, description, model name).
  • New CHANGELOG files are all-stub placeholders as described in the PR, to be backfilled later — no functional code.
  • The workflow addition is a new step that calls an external action pinned to @v1; failure is explicitly designed to only warn (not fail the release), per the inline comments, so it shouldn't break the release pipeline.
  • No changes to existing build/push logic — purely additive.

Nothing here looks like an accidentally committed credential, obvious logic bug, or breaking change.

*Automated review by [pr-reviewer](https://git.brooktrails.org/brooktrails/pr-reviewer) v0.41.0 | Safety Check | Claude Sonnet 5 | tracking id `r-6485aa-e9f289`* *This is an AI-generated review and may contain mistakes.* **Status:** ✅ Completed --- > ⚠️ The primary review (**Mistral Small**) failed. The review below is from **Claude Sonnet 5**, which reviewed the same diff. **✅ Verdict: LGTM** — No real secrets or breaking changes present; the flagged "secret" is just a normal secrets.FORGEJO_TOKEN reference, and the rest is additive stub/config content. Reviewed the diff carefully. The automated "possible secret" flag is a false positive: the workflow only references `secrets.FORGEJO_TOKEN` and `vars.INFERENCE_URL` via standard Forgejo Actions expression syntax — no literal credentials are embedded. This is the normal, correct way to pass secrets into a CI step. The rest of the change is low-risk: - New `.changelog.env` contains only non-sensitive product metadata (name, description, model name). - New CHANGELOG files are all-stub placeholders as described in the PR, to be backfilled later — no functional code. - The workflow addition is a new step that calls an external action pinned to `@v1`; failure is explicitly designed to only warn (not fail the release), per the inline comments, so it shouldn't break the release pipeline. - No changes to existing build/push logic — purely additive. Nothing here looks like an accidentally committed credential, obvious logic bug, or breaking change.
docs(changelog): fill in the remaining stub entries
All checks were successful
ci / test_and_build (pull_request) Successful in 24s
2573450704
Every release entry across the three changelogs now carries a real summary;
none are left as "STUB: N bytes of changes." placeholders. 42 sections in
each file, one per tag.

0.4.0 is the exception, and says so: v0.4.0 and v0.3.0 point at the same
commit (6a2c3b6), so its range is empty and there is nothing to describe.
Its entry states that the release contains no changes, which no amount of
regeneration could have produced -- the tooling correctly refuses to invent
a summary for an empty range.

Entries wrap at 78 columns, CJK runs that offer no break point excepted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Collaborator

Automated review by pr-reviewer v0.41.0 | Safety Check | Claude Sonnet 5 | tracking id r-65c2f6-3dead2
This is an AI-generated review and may contain mistakes.

Status: Completed


⚠️ The primary review (Mistral Small) failed. The review below is from Claude Sonnet 5, which reviewed the same diff.

Verdict: LGTM — The automated flags (secret pattern, high entropy, large new files) are all false positives — they correspond to normal secrets-context syntax, CJK text entropy, and legitimate generated changelog content respectively; no real issue found.

Reviewed the diff:

  • The workflow change uses secrets.FORGEJO_TOKEN and vars.INFERENCE_URL via standard Forgejo Actions expression syntax — these are secret/variable references, not literal exposed credentials. This is the normal, safe way to pass secrets into an action; the "possible secret detected" flag is a false positive from the automated scanner picking up the word "token"/"secret" in context.
  • .changelog.env contains only non-sensitive product metadata (name, description, model name) — no keys or credentials.
  • CHANGELOG.md/.es.md/.zh.md are large but are plain-text generated changelog content (confirmed by reading the diff), not vendored binaries or minified code. The "high entropy" flag on the Chinese file is expected/normal for CJK text (which has inherently higher per-character entropy than Latin text) — not a sign of encoded/binary data.
  • The new changelog-action step is appended after the tag push, is continue-on-error-style ("a changelog failure only warns, never fails the release" per description, though I'd note the workflow snippet shown doesn't include an explicit continue-on-error: true — worth double-checking that behavior is actually enforced in the action/workflow, but not something to block on since the action is external and described as swallowing errors itself).
  • No obvious secrets, malicious code, or breaking changes to existing build steps; the new step is additive and placed after existing critical steps (push image, push tag).

Nothing here looks like it shouldn't have been pushed — the automated flags are explainable as false positives (secret-reference syntax, CJK entropy, and expected new large text files for a changelog backfill).

*Automated review by [pr-reviewer](https://git.brooktrails.org/brooktrails/pr-reviewer) v0.41.0 | Safety Check | Claude Sonnet 5 | tracking id `r-65c2f6-3dead2`* *This is an AI-generated review and may contain mistakes.* **Status:** ✅ Completed --- > ⚠️ The primary review (**Mistral Small**) failed. The review below is from **Claude Sonnet 5**, which reviewed the same diff. **✅ Verdict: LGTM** — The automated flags (secret pattern, high entropy, large new files) are all false positives — they correspond to normal secrets-context syntax, CJK text entropy, and legitimate generated changelog content respectively; no real issue found. Reviewed the diff: - The workflow change uses `secrets.FORGEJO_TOKEN` and `vars.INFERENCE_URL` via standard Forgejo Actions expression syntax — these are secret/variable references, not literal exposed credentials. This is the normal, safe way to pass secrets into an action; the "possible secret detected" flag is a false positive from the automated scanner picking up the word "token"/"secret" in context. - `.changelog.env` contains only non-sensitive product metadata (name, description, model name) — no keys or credentials. - CHANGELOG.md/.es.md/.zh.md are large but are plain-text generated changelog content (confirmed by reading the diff), not vendored binaries or minified code. The "high entropy" flag on the Chinese file is expected/normal for CJK text (which has inherently higher per-character entropy than Latin text) — not a sign of encoded/binary data. - The new changelog-action step is appended after the tag push, is `continue-on-error`-style ("a changelog failure only warns, never fails the release" per description, though I'd note the workflow snippet shown doesn't include an explicit `continue-on-error: true` — worth double-checking that behavior is actually enforced in the action/workflow, but not something to block on since the action is external and described as swallowing errors itself). - No obvious secrets, malicious code, or breaking changes to existing build steps; the new step is additive and placed after existing critical steps (push image, push tag). Nothing here looks like it shouldn't have been pushed — the automated flags are explainable as false positives (secret-reference syntax, CJK entropy, and expected new large text files for a changelog backfill).
docs(changelog): drop pipeline internals from the headers
All checks were successful
ci / test_and_build (pull_request) Successful in 24s
fb8ca42adc
A reader of the changelog needs to know two things about how it is made:
that it is maintained automatically, and that the entries are LLM-generated.
Both are already stated further up. Naming the build pipeline, the shared
action, the inference service, and the host it sits behind told them about
infrastructure they have no way to reach and no reason to care about.

The translation cross-references stay -- those are for the reader.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Collaborator

Automated review by pr-reviewer v0.41.0 | Safety Check | Claude Sonnet 5 | tracking id r-65c76f-04e01f
This is an AI-generated review and may contain mistakes.

Status: Completed


⚠️ The primary review (Mistral Small) failed. The review below is from Claude Sonnet 5, which reviewed the same diff.

Verdict: LGTM — No real secrets, binaries, or logic bugs found; the automated flags (secret reference, high entropy in Chinese text) are false positives.

Reviewed the diff:

  • The "possible secret" flag in build-push.yaml is a false positive: it's token: ${{ secrets.FORGEJO_TOKEN }}, a standard reference to a secret stored in Forgejo's secrets store, not a hardcoded credential. No literal secret value is present in the diff.
  • The "high entropy" flag on CHANGELOG.zh.md is expected/benign — it's Chinese-language prose, which naturally has higher bits/char entropy than English text due to CJK character density. Not binary/encoded data.
  • The new CHANGELOG.md/.es.md/.zh.md files are large but are legitimate content (changelog text), not vendored code, matching the PR's stated intent.
  • Workflow change adds a new step guarded to only warn (not fail) on error, per the description, and runs after the tag push — reasonable, low-risk placement.
  • No secrets, credentials, or binaries appear to be accidentally committed.

Everything here matches the PR's stated intent and the automated flags are explainable false positives.

*Automated review by [pr-reviewer](https://git.brooktrails.org/brooktrails/pr-reviewer) v0.41.0 | Safety Check | Claude Sonnet 5 | tracking id `r-65c76f-04e01f`* *This is an AI-generated review and may contain mistakes.* **Status:** ✅ Completed --- > ⚠️ The primary review (**Mistral Small**) failed. The review below is from **Claude Sonnet 5**, which reviewed the same diff. **✅ Verdict: LGTM** — No real secrets, binaries, or logic bugs found; the automated flags (secret reference, high entropy in Chinese text) are false positives. Reviewed the diff: - The "possible secret" flag in build-push.yaml is a false positive: it's `token: ${{ secrets.FORGEJO_TOKEN }}`, a standard reference to a secret stored in Forgejo's secrets store, not a hardcoded credential. No literal secret value is present in the diff. - The "high entropy" flag on CHANGELOG.zh.md is expected/benign — it's Chinese-language prose, which naturally has higher bits/char entropy than English text due to CJK character density. Not binary/encoded data. - The new CHANGELOG.md/.es.md/.zh.md files are large but are legitimate content (changelog text), not vendored code, matching the PR's stated intent. - Workflow change adds a new step guarded to only warn (not fail) on error, per the description, and runs after the tag push — reasonable, low-risk placement. - No secrets, credentials, or binaries appear to be accidentally committed. Everything here matches the PR's stated intent and the automated flags are explainable false positives.
rcsheets deleted branch feat/changelog-action 2026-07-26 08:40:26 +00:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
brooktrails/gllm!56
No description provided.