celilo/homepage
2
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Finish 0.2.0 before it publishes: changelog text + forge_repo after the org move #3

Merged
forgejo-admin merged 2 commits from changelog-0.2.0-text into main 2026-08-18 07:58:53 +00:00
Conversation 0 Commits 2 Files changed 2 +2 -2
forgejo-admin commented 2026-08-18 07:52:51 +00:00
Owner
Copy link

Two small corrections to 0.2.0, both of which have to land before it publishes. 0.2.0 is still unpublished (registry is at 0.1.0+1), so this is the window.

1. forge_repo → celilo/homepage

The repo just moved from forgejo-admin/homepage into the celilo org so that celilo's Forgejo runner (registered runner_org: celilo) will actually claim its release runs. No forgejo-admin repo had ever had a run succeed, and the run queued on the old repo sat in waiting and did not come across with the transfer.

forge_repo is what on_install hands to source_forge.registerRepo to mint CELILO_PUBLISH_TOKEN. Left pointing at the old path, the next deploy would register the wrong repo and set the secret somewhere CI never reads it. This reverts 7f41b94 back to the celilo/homepage default it had before.

release.yml needed no change — it derives everything from ${GITHUB_REPOSITORY}, so it followed the transfer on its own. The manifest default was the only hardcoded reference in the tree.

2. The placeholder changelog line

celilo module version stamped 0.2.0 from two changesets. One described the capabilities bump; the other was boilerplate from 0be59b3:

- minor change to peterbanka-org.

It covers real unreleased work (0be59b3 and 7f41b94), so deleting it would have changed the bump. The minor level is correct and stays; only the text was wrong. Rewritten to describe the forge registration, the scoped publish token, the changeset-driven release workflow, and the optional-capability fallback.

The two changes are folded together because the rewritten changelog sentence names the forge_repo default. Landing them separately would leave a stale sentence in whichever merged first.

Verification

  • tsc --noEmit -p celilo-module/scripts/tsconfig.json — clean.
  • celilo module check ./celilo-module — 7 ok, 0 fail.
  • manifest.yml version untouched at 0.2.0; .changeset/ holds only README.md, so nothing re-bumps to 0.3.0.

What happens on merge

This is a push to main, which is what release.yml triggers on. With the repo now in the celilo org there should finally be a runner to claim it, and with no pending changesets the version job should short-circuit to should_publish=true and the publish job should PUT 0.2.0 to celilo-registry.

I will confirm by querying the registry, not by reading a green run.

🤖 Generated with Claude Code

Two small corrections to 0.2.0, both of which have to land **before** it publishes. 0.2.0 is still unpublished (registry is at `0.1.0+1`), so this is the window. ## 1. `forge_repo` → `celilo/homepage` The repo just moved from `forgejo-admin/homepage` into the `celilo` org so that celilo's Forgejo runner (registered `runner_org: celilo`) will actually claim its release runs. No `forgejo-admin` repo had ever had a run succeed, and the run queued on the old repo sat in `waiting` and did not come across with the transfer. `forge_repo` is what `on_install` hands to `source_forge.registerRepo` to mint `CELILO_PUBLISH_TOKEN`. Left pointing at the old path, the next deploy would register the wrong repo and set the secret somewhere CI never reads it. This reverts `7f41b94` back to the `celilo/homepage` default it had before. `release.yml` needed no change — it derives everything from `${GITHUB_REPOSITORY}`, so it followed the transfer on its own. The manifest default was the only hardcoded reference in the tree. ## 2. The placeholder changelog line `celilo module version` stamped 0.2.0 from two changesets. One described the capabilities bump; the other was boilerplate from `0be59b3`: ``` - minor change to peterbanka-org. ``` It covers real unreleased work (`0be59b3` and `7f41b94`), so deleting it would have changed the bump. The **minor** level is correct and stays; only the text was wrong. Rewritten to describe the forge registration, the scoped publish token, the changeset-driven release workflow, and the optional-capability fallback. The two changes are folded together because the rewritten changelog sentence names the `forge_repo` default. Landing them separately would leave a stale sentence in whichever merged first. ## Verification - `tsc --noEmit -p celilo-module/scripts/tsconfig.json` — clean. - `celilo module check ./celilo-module` — 7 ok, 0 fail. - `manifest.yml` version untouched at `0.2.0`; `.changeset/` holds only `README.md`, so nothing re-bumps to 0.3.0. ## What happens on merge This is a push to `main`, which is what `release.yml` triggers on. With the repo now in the `celilo` org there should finally be a runner to claim it, and with no pending changesets the `version` job should short-circuit to `should_publish=true` and the `publish` job should PUT 0.2.0 to celilo-registry. I will confirm by querying the registry, not by reading a green run. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
`celilo module version` stamped 0.2.0 from two changesets. One described
the capabilities bump; the other was the auto-generated boilerplate
"minor change to peterbanka-org." added in 0be59b3 when CI was first
wired up, which says nothing about what changed.

It covered real unreleased work, so the bump is right and stays minor.
Only the text was wrong. Rewritten to describe 0be59b3 and 7f41b94: the
forge registration in on_install, the scoped publish token, the
changeset-driven release workflow, and the forge_repo default.

CHANGELOG text only. No version change, no new changeset, and 0.2.0 is
not published yet (registry is still at 0.1.0+1), so this lands before
the entry becomes permanent.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The repo moved from forgejo-admin/homepage to celilo/homepage so that
celilo's Forgejo runner, registered runner_org: celilo, will actually
claim its release runs. No forgejo-admin repo had ever had a run
succeed; the queued run on the old repo sat in `waiting` and did not
come across with the transfer.

forge_repo is what on_install hands to source_forge.registerRepo to mint
CELILO_PUBLISH_TOKEN. Left pointing at the old path, the next deploy
would register the wrong repo and set the secret somewhere CI never
reads it. This reverts 7f41b94 back to the celilo/homepage default it
had before.

release.yml needed no change: it derives everything from
${GITHUB_REPOSITORY}, so it followed the transfer on its own. The
manifest default was the only hardcoded reference in the tree.

Also updates the 0.2.0 changelog sentence naming that default, so the
two do not disagree.

Still no version bump and no new changeset: 0.2.0 is unpublished
(registry is at 0.1.0+1), so this belongs in that entry.

  tsc --noEmit         clean
  celilo module check  7 ok, 0 fail

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
forgejo-admin changed title from Replace the placeholder 0.2.0 changelog entry with what shipped to Finish 0.2.0 before it publishes: changelog text + forge_repo after the org move 2026-08-18 07:58:42 +00:00
forgejo-admin deleted branch changelog-0.2.0-text 2026-08-18 07:58:53 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
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
celilo/homepage!3
No description provided.