Site: published by CI after a push to main and after a release (#79) #80

2026-10-07T12:34:08Z

twisla commented

2026-10-07 12:34:08 +00:00

For #79: the site is rebuilt by CI, not by hand.

Site workflow: a last step, after the build and the checks, on a push to main only.
Release workflow: the same step after a release is published, since the home page and Downloads name the latest release when they are built.
scripts/site_refresh.sh: connects with one key, strict host key checking and no command. The server's authorized_keys line forces the command (restrict,command="..."), so the key can do nothing else.
scripts/site_deploy_keygen.sh: makes the key once and prints the authorized_keys line and the four secrets (SITE_DEPLOY_KEY, SITE_DEPLOY_HOST, SITE_DEPLOY_USER, SITE_DEPLOY_KNOWN_HOSTS).

Until the secrets exist the step does nothing and says so, so this can be merged first.

Checked against an SSH server in a throwaway container: the refresh runs; asking for another command runs the refresh instead; no terminal; scp copies nothing; a different host key stops the run; a failing server script fails the step. Not checked: the real server and runner, port forwarding, and from=.

Design and checks: docs/milestones/W1.md, "Published by CI" (Q214 to Q222).

🤖 Generated with Claude Code

https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT

For #79: the site is rebuilt by CI, not by hand. - **Site workflow:** a last step, after the build and the checks, on a push to `main` only. - **Release workflow:** the same step after a release is published, since the home page and Downloads name the latest release when they are built. - **`scripts/site_refresh.sh`:** connects with one key, strict host key checking and no command. The server's `authorized_keys` line forces the command (`restrict,command="..."`), so the key can do nothing else. - **`scripts/site_deploy_keygen.sh`:** makes the key once and prints the `authorized_keys` line and the four secrets (`SITE_DEPLOY_KEY`, `SITE_DEPLOY_HOST`, `SITE_DEPLOY_USER`, `SITE_DEPLOY_KNOWN_HOSTS`). Until the secrets exist the step does nothing and says so, so this can be merged first. **Checked** against an SSH server in a throwaway container: the refresh runs; asking for another command runs the refresh instead; no terminal; `scp` copies nothing; a different host key stops the run; a failing server script fails the step. **Not checked:** the real server and runner, port forwarding, and `from=`. Design and checks: docs/milestones/W1.md, "Published by CI" (Q214 to Q222). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT

twisla added 1 commit 2026-10-07 12:34:10 +00:00

Site: published by CI after a push to main and after a release (#79 )

Site / build (pull_request) Successful in 11s

Details

CI / build (pull_request) Successful in 1m20s

Details

12c88c98d3

The Site workflow's last step, and the release workflow after publishing,
ask the web server over SSH to rebuild the site. The key CI holds is tied
on the server to one forced command (restrict,command=...), so CI sends no
command and a leaked key can only refresh the site. The server, the user,
the key and the server's host key are Gitea secrets; with none of them set
the step does nothing.

scripts/site_refresh.sh is what both workflows run;
scripts/site_deploy_keygen.sh makes the key and prints where each half goes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT

twisla merged commit 10c5291e15 into main

2026-10-07 12:49:22 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: twisla/roro9stack#80