main requires signed commits, so the pull request the bump job opens after a
release cannot be merged while the commit in it is unsigned. The key the server
signs merge commits with is not reachable from a runner, so the job signs with a
dedicated release-bot SSH key that the instance trusts through
TRUSTED_SSH_KEYS — no bot account, because an account key is only consulted
after the web Verify flow and that flow has no API.
Inert until the key is trusted and RELEASE_BOT_SIGNING_KEY is set, and loudly so:
the step checks the secret and ssh-keygen before it starts, runs the key through
ssh-keygen -y so a truncated or re-wrapped one is caught as itself rather than as
"gpg failed to sign the data", and the commit is re-read for a gpgsig header
before it is pushed.
Co-Authored-By: Claude Opus 5 <[email protected]>
The bump job has never once worked. Its first step died in two seconds on
`set: Illegal option -o pipefail` -- it is the only job here that runs in a
container, and a container job is handed `sh -e {0}` rather than the bash the
runner gives its own jobs. Dash has no `pipefail`, and no `10#` either, so the
arithmetic on the line after would have gone the same way. It now asks for
bash, which node:22 carries.
That would have got the job as far as its last step, which pushed straight to
main. Nothing had ever exercised that, and it needs the token to be allowed
past whatever protects the branch -- hence the second token, VERSION_BUMP_TOKEN,
standing by for where it is not. unsupervised-scheduler has been bumping its
version on every release for a while by pushing a branch and opening a pull
request with the ordinary task token, so that is what this does now. The second
token is no longer needed, and neither is `[skip ci]`: main is never pushed, so
there is no build of the just-published image to suppress. The pull request
puts the changed package.json through a build before it lands.
scheduler builds the request body with jq because its CI image carries jq. This
one is node:22, where node is the thing that certainly is there.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XBT25ZDzm453A8XViSRqRB
package.json has sat at 0.1.0 since the first commit, through three releases,
because nothing read it. That is fine right up until something does — an image
label, a health endpoint, a bug report quoting a version — at which point the
tree claims to be a version that shipped long ago.
A new `bump` job takes the tag that was just published, works out the next
patch from it, and commits that to main. After 1.2.0 the tree says 1.2.1: not
a version that exists, which is the point. A build from main is then legible
as "after 1.2.0" rather than as 1.2.0 itself.
It sits in publish.yml rather than a workflow of its own so that it can say
`needs: build`. A version that failed to publish has not been released, and
moving past it would say that it had. Prereleases are skipped for the same
reason -- 1.2.3-rc1 is a candidate for a version that has not shipped, so
there is nothing yet to move past.
The bump goes through `npm version` rather than editing the file. The version
is in the lockfile too, in two places, and a tree where those disagree is worse
than one that is merely out of date.
Three smaller things. The patch arithmetic forces base ten, because a patch
number written 08 is otherwise read as octal and kills the job. The commit
carries `[skip ci]`, or pushing it starts another build of the image that was
just published. And the committer is a name that is not a person at a reserved
address that can never become one, so nothing here names the instance it runs
on.
Pushing to main needs a token that may write to the repository. The Actions
task token can where the instance allows it; where it does not, setting a
VERSION_BUMP_TOKEN secret overrides it. A push that is refused fails the job
with both of those as the suggestion rather than a bare 403.
package.json goes to 1.2.1 here, which is where the job would have left it had
it existed when 1.2.0 went out.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_017nMQ2eDKnqALYhAibpTKTu
Workflow tag filters are glob patterns, so the `[0-9]+` in the previous
version had `+` read as a literal plus and would never have matched 1.0.0 —
the release would have pushed a tag and quietly built nothing.
`[0-9]*.[0-9]*.[0-9]*` uses only basic glob, matches 1.2.3 and 1.2.3-rc1
alike, and still ignores tags that are not versions. The prerelease patterns
collapse into it, since the trailing wildcard already absorbs a suffix.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BGkRmLfiWuJHx6tQ12EELY
The first publish failed partway through the push with 413 Payload Too Large:
one layer was bigger than the proxy in front of the registry would accept.
Three changes, only one of which is that fix.
Keep deployment out of a public repo. The registry, image name and credentials
now come from repository variables and secrets rather than being written down
here, and the docs describe how to run the thing rather than where one
particular instance runs. PUBLIC_ORIGIN defaults to localhost. The 413 is a
proxy limit, so the fix is pointing REGISTRY at a host the runner reaches
directly; the workflow explains itself if that host is plain HTTP and the
builder's daemon has not been told to allow it.
Publish on version tags. A tag like 1.2.3 publishes :1.2.3, :1.2, :1 and
:latest; a prerelease publishes only its exact version and leaves :latest
alone. Pushes to main publish :main and :sha-<short> and no longer move
:latest, so what is deployed moves when a release says so.
Shrink the image from over 1.2GB to 353MB. The Playwright base image carries
Firefox and WebKit, which this never launches. Installing just the browser it
does launch onto a slim Node base drops two thirds of the weight, which is
worth having on a Raspberry Pi even though it does not get any single layer
under a proxy limit.
That last change surfaced something worth naming: a headless launch resolves to
Playwright's headless shell, not the full browser, so that is what every test
so far has actually been running. The image now installs exactly that binary
and pool.ts names the channel, so the two cannot drift apart.
Verified in the container: Bluesky, Instagram, X and Threads all resolve
identically on the slim image.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BGkRmLfiWuJHx6tQ12EELY
antisocial is the other half of a StopTheMadness redirect rule. Links to X,
Threads, Instagram, TikTok and Bluesky get rewritten to /<prefix>/<original
path>, and this resolves the post and shows the media and the words, with a
badge saying where it came from and a button to copy the original URL.
Every request drives a real headless Chromium, logged out, from a residential
IP. One code path, and it survives markup changes better than parsing from the
outside would. Extraction is layered, most structured first: the platform's own
API response caught in flight, then an inline payload, then the rendered DOM,
then Open Graph tags.
Media is never linked straight at a CDN. Instagram and TikTok reject requests
without a matching Referer and cookies, and proxying keeps the viewer's browser
from talking to the platform at all. Range is forwarded so the native video
scrubber can seek. HLS is the exception, since proxying it would mean rewriting
playlists.
TikTok sometimes answers with a slider puzzle. Rather than reporting that as a
failure, the page is parked and the viewer is handed the puzzle: screenshots
stream out, pointer events are replayed back. Solving it leaves the cookie in
the shared browser context, so the retry is an ordinary request.
A failed resolve is never a blank error page. The card carries the platform, the
original URL and the copy button, so a broken adapter still leaves the link one
tap away.
Verified end to end against real shared links on all five platforms, in the
container, including multi-image carousels, reels, TikTok short links and photo
posts. 49 tests run the adapters against captured payloads with no network.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BGkRmLfiWuJHx6tQ12EELY
KydoimosandClaude Opus 5
thatguygriffandClaude Opus 5