Add Fly.io deploy workflow triggered on release#56
Open
cubny wants to merge 1 commit into
Open
Conversation
Releases previously ran goreleaser only, which publishes binaries to the GitHub Release. Nothing built or pushed an image to fly.io, so every deploy since the app launched was a manual `fly deploy`. Tagging v3.3.1 therefore left production running the May 20 image. Deploy on `release: created` to match the existing release.yml trigger, plus workflow_dispatch for manual re-runs. Authenticates with a deploy-scoped FLY_API_TOKEN stored in repo secrets. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Tagging
v3.3.1did not deploy anything to fly.io, and no new image appeared in the registry.Root cause: there is no fly.io deploy automation in this repo, and there never has been.
release.ymlruns goreleaser only — it cross-compiles binaries and attaches zips to the GitHub Release. It never builds a Docker image and never contacts fly.io.fly.toml(added in 6835a08, "Fly.io Launch config files") makesfly deploywork from a laptop, but no CI step ever calls it.flyctl releasesshows 5 releases, all created manually bycubny@duck.com, the most recent on May 20 2026. Production has been serving that image ever since.grep -ri "flyctl|fly deploy|FLY_API_TOKEN"across the repo returned zero hits.The application code was never the problem — the scheduler fix landed on master as
aedd415, and CI'sdocker-buildjob confirms the image builds cleanly.Fix
Adds
.github/workflows/fly-deploy.yml, which runsflyctl deploy --remote-onlyonrelease: created— matching the existingrelease.ymltrigger, so tagging a release now both publishes binaries and deploys.workflow_dispatchis included so a deploy can be re-run by hand without cutting a new release.A
concurrencygroup prevents two deploys from racing.Setup already done
github-actions-deployon thelite-readerapp, expiring 2027-07-10 (flyctl defaults to a 20-year expiry; 1 year is more appropriate for a CI credential).FLY_API_TOKEN.Verifying after merge
This workflow can't run until it's on the default branch. Once merged, trigger it manually to deploy the already-released v3.3.1:
Then confirm
flyctl status --app lite-readerreports a machine updated today rather than 2026-05-20.Note: the deploy checks out the ref the workflow ran on. Dispatching against
masterdeploys master's tip; arelease: createdrun deploys the tag.🤖 Generated with Claude Code