Skip to content

docs(release): point skill at workflow-driven mechanism (gh workflow run release.yml)#28

Open
sanity wants to merge 1 commit into
mainfrom
update-release-skill-for-workflow-mechanism
Open

docs(release): point skill at workflow-driven mechanism (gh workflow run release.yml)#28
sanity wants to merge 1 commit into
mainfrom
update-release-skill-for-workflow-mechanism

Conversation

@sanity
Copy link
Copy Markdown
Contributor

@sanity sanity commented May 16, 2026

Problem

The release skill instructs agents to run scripts/release.sh --version X.Y.Z and SSH into gateways manually. freenet-core's release pipeline was rewritten across PRs #4082, #4114, #4115, #4118-4124, #4135, and #4136 to be fully workflow-driven: gh workflow run release.yml triggers the entire cascade including crates.io publish, tag push, cross-compile, gateway updates via HTTP webhooks, and Matrix/River announcements.

v0.2.58 was the first release cut through this new path — both gateways converged automatically and Matrix posted automatically.

The canonical procedure now lives in freenet-core/docs/RELEASING.md.

This skill was still telling agents to use the old SSH-driven path, which:

  • Still works as a fallback, but
  • Double-posts to Matrix/River if used while the workflow path is also in play (the workflow uses a deterministic TXN_ID; matrix-commander does not)
  • Skips the new path entirely, defeating the point of the rewrite

Solution

Replace Step 4 (the release execution) with the gh workflow run invocation. Point readers at docs/RELEASING.md as the source of truth. Document the prerequisite repo secrets and per-secret failure modes.

Rewrite Step 7 (Announcements) to note that announcements are automatic, with a gh workflow run release-announce.yml manual re-fire command for failure recovery.

Leave the verification steps (5, 6, 6.5, 8) untouched — they're path-agnostic.

Testing

The new procedure was validated end-to-end by cutting v0.2.58 via gh workflow run release.yml. Both gateways converged, Matrix posted, the cascade auto-fired on release.published (because RELEASE_PAT was set per the new requirement documented in AGENTS.md).

[AI-assisted - Claude]

freenet-core's v0.2.58 release went through `gh workflow run release.yml`
end-to-end (see freenet-core PRs #4082, #4114, #4115, #4118-4124, #4135,
#4136). The canonical procedure now lives in
freenet-core/docs/RELEASING.md.

This skill previously instructed agents to run `scripts/release.sh
--version X.Y.Z` and SSH into gateways manually. That path:
- Still works as a fallback, but
- Double-posts to Matrix/River if used while the workflow path is also
  in play (the workflow's Matrix announcement is deduped per-version via
  deterministic TXN_ID; the local script's matrix-commander post is not).

This commit:
- Replaces Step 4 with the `gh workflow run release.yml` invocation
  (both bare auto-bump form and explicit `--field version=X.Y.Z`).
- Documents the prerequisite repo secrets and what each one's failure
  mode looks like.
- Drops the per-step pipeline description that was bound to release.sh
  internals; refers readers to docs/RELEASING.md as the source of truth.
- Calls out the legacy script + the env vars
  (`FREENET_RELEASE_SKIP_ANNOUNCEMENTS=1`,
  `FREENET_RELEASE_SKIP_GATEWAY_SSH=1`) for emergency use.
- Rewrites Step 7 to note announcements are automatic, with a manual
  re-fire command if `release-announce.yml` fails.

The verification steps (5, 6, 6.5, 8) are unchanged — those still
apply, the artifact paths and smoke tests aren't affected.

Tested manually for v0.2.58 (gateways converged, Matrix posted).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant