Repository navigation
Deploy labelled PRs to staging with prod data and smoke tests - #235
Draft
jzhou-otterai wants to merge 2 commits into
Draft
jzhou-otterai wants to merge 2 commits into
jzhou-otterai wants to merge 2 commits into
Conversation
Adding the `staging` label to a PR builds its images on GitHub runners, pushes them to GHCR, and deploys them to the server-infra EC2 box. Later pushes redeploy automatically, and a manual run can deploy main or any PR by number. Staging is a single slot, so deploying one PR takes the label off the previous one. The box runs a root-owned `uwflow-staging` command, installed from main and reached through a forced SSH command. A PR can therefore supply only images plus its hasura/ and nginx/ trees, never code that runs next to the production credentials. Data refreshes copy the newest prod dump with scp, restore it into a scratch database, and swap it in only after a clean restore. The importer and email worker never start. Port 22 is opened to the runner's IP only for the length of the job, through an OIDC role scoped to the box's security group. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Drop the registry, the staging compose override, and the root-owned deploy tooling on the box. The workflow now builds api and frontend with script/build.sh on the free 4-vCPU runner and streams the images over SSH with docker load. On the box it checks out the same commit and runs fetch-dump.sh plus make setup when data needs refreshing. Then it starts postgres, hasura, api and frontend from docker-compose.yml. Two small changes make the existing scripts work on the box: - Hasura listens on $HASURA_PORT, so a host whose 8080 is taken can move it in .env. Production is unchanged, since it uses 8080 either way. - start.sh falls back to `docker compose` on hosts without the v1 docker-compose binary. Co-Authored-By: Claude Opus 5.5 <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
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.
Summary
Add the
staginglabel to a PR to deploy it to the staging box (the server-infra EC2 instance at3.135.22.212). Each later push to that PR redeploys it. Run workflow can also deploymainor a PR by number, and can refresh staging's data from production.The workflow reuses the existing scripts instead of adding new tooling. It runs as one job on
ubuntu-latest, which is the free 4 vCPU / 16 GB runner for public repos; the org's Free plan can't use larger runners.script/build.sh api frontendbuilds the images, taggedneuwflow/<service>:<sha>just like production builds.docker save | ssh … docker loadcopies the images to the box. Nothing is pushed to a registry.~/uwflowchecks out the same commit, so the migrations, Hasura metadata and nginx config match the images.script/fetch-dump.sh uwflow-prodand thenmake setup.docker compose up -d postgres hasura api frontendstarts the stack.uwandemailstay off, becauseemailwould send mail to real users from the production queue.index.htmlloads, anonymous GraphQL returns courses,/api/data/searchworks, the Hasura metadata is consistent, and no container is crash-looping.Deploying a PR also removes the
staginglabel from the PR that held it before.Two small changes make the existing scripts work on the box:
docker-compose.yml: Hasura now listens on$HASURA_PORT, so staging can move it off 8080, which server-infra's nginx already uses. Production uses 8080 either way, so nothing changes there.script/start.sh: falls back todocker composewhen thedocker-composev1 binary is missing, which is the case on the box.The one-time setup (box
.env, prod SSH config, AWS role, GitHub environment) is indocs/staging.md.Testing
actionlintpasses.script/test-monorepo.pypasses. Shellcheck finds no new warnings instart.sh.docker compose configwithHASURA_PORT=18080renders the expected ports, theHASURA_GRAPHQL_SERVER_PORTenv var and theneuwflow/*:<sha>images. The cli-migrations Hasura image serves/healthzon 18080.make setupwasn't run locally, because it would wipe the localbackend_postgresvolume.🤖 Generated with Claude Code