ci: add a manual deploy workflow (Actions → Deploy) - #34
Merged
Conversation
Deploys were a laptop with Docker, the SSH key and a good connection. Nothing tied a deploy to a reviewed commit, and nothing surfaced drift — production ran a 12-day-old build against a current frontend without any signal, which is how the live checkout 500 happened. Actions tab → Deploy → Run workflow. Manual on purpose: merging should not ship to customers on its own, but a deploy should not depend on one machine either. It re-runs vet and the tests before building, because workflow_dispatch is not gated on the CI workflow and "it passed on the PR" is not the same as "it passes at the commit being deployed". The release is ordered so a failure cannot take the site down: the exact tag is pulled first, compose is only then repointed at an image the host already holds, and the container is restarted. If /health does not answer within 60s it restores the previous image and fails the run. The public endpoint is checked afterwards as well, since localhost being healthy says nothing about what customers reach. Images are tagged by commit as well as latest, so a rollback is re-running this against the previous commit rather than rebuilding it. scripts/deploy.sh stays as the break-glass path and now repoints compose back at the local image, since the workflow leaves it on a ghcr.io tag. It also asks before shipping and warns on a dirty tree.
Contributor
Deploying hookdrop with
|
| Latest commit: |
7c8f2b1
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://3f2673c4.hookdrop.pages.dev |
| Branch Preview URL: | https://chore-ci-and-currency-guard.hookdrop.pages.dev |
Contributor
Deploying hookdrop-frontend with
|
| Latest commit: |
7c8f2b1
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://80c4f7dd.hookdrop-frontend.pages.dev |
| Branch Preview URL: | https://chore-ci-and-currency-guard.hookdrop-frontend.pages.dev |
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.
Answers "is there a new way to deploy?" — there is now, for the backend. The frontend already auto-deployed from
mainvia Cloudflare Pages and still does.Why
Deploying meant a laptop with Docker, the SSH key and a good connection. Nothing tied a deploy to a reviewed commit, and nothing surfaced drift: production ran a 12-day-old build against a current frontend with no signal at all. That is what produced the live checkout 500.
How it works
Actions → Deploy → Run workflow. Manual by design: merging should not ship to customers by itself, but a deploy should not depend on one machine either. Takes a ref, defaults to
main.The release is ordered so a failed deploy cannot take the site down:
go vetand the tests at the commit being deployed —workflow_dispatchis not gated on the CI workflow, and "it passed on the PR" is not the same as "it passes here"linux/amd64, pushesghcr.io/eoeboh/hookdrop:<sha>and:latestdocker-compose.ymland snapshots the DB after a clean shutdown (WAL checkpointed)/healthfor 60shttps://api.hookdrop.app/healthfrom outside and checks uptime is fresh — localhost being healthy says nothing about what customers reachRollback is re-running the workflow against the previous commit; images are tagged per commit so nothing needs rebuilding.
Setup already done
ed25519deploy key generated, installed in the server'sauthorized_keys(previous file backed up), and verified. Your personal key is untouched.DEPLOY_SSH_KEY,DEPLOY_HOST,DEPLOY_USERset as repo secrets. The private key was written to GitHub and deleted locally.One manual step remains: the first run publishes the GHCR package as private. Either make
ghcr.io/eoeboh/hookdroppublic (the image holds only the compiled binary — all secrets come from compose env on the server) ordocker login ghcr.ioonce on the box. Without one of those the server cannot pull.scripts/deploy.sh
Kept as break-glass, and fixed: it now repoints compose back at the local image, since the workflow leaves it on a
ghcr.iotag and the old script would otherwise conflict. It also confirms before shipping and warns when the tree is dirty.Testing
workflow_dispatchonly appears once the workflow is on the default branch, so this cannot be exercised until it merges. Happy to run it and verify the whole path — including a deliberate rollback — once it is in.