name: Deploy to LAN dev server # Fires on every push to `dev` -- a direct push, or the real merge commit a # native "auto merge when checks succeed" produces (see pr-build.yml). Mirrors # the monorepo's deploy-dev.yml shape: a `build` job (the build.yml sanity # check, reused) followed by a `deploy` job that rolls the LAN dev box. # # Unlike the monorepo (a single repo, so deploy-dev.sh lived in the same # checkout this workflow ran `actions/checkout` on), this repo publishes only # an image (build-push.yml, already triggers on push to dev and tags it # sha-<12hex> in the Forgejo registry) -- deploy-dev.sh itself now lives in # the INFRA repo's checkout on the runner host, at ~/thermograph-dev (it # self-updates there via its own `git reset` against thermograph-infra, same # pattern deploy.sh/deploy-prod.sh already use for main/release). That means # this job is INERT until the thermograph-lan box is reprovisioned from its # current monorepo checkout to an infra checkout -- there is no # ~/thermograph-dev/deploy/deploy-dev.sh on the box yet for this step to run. # # SERVICE=backend + BACKEND_IMAGE_TAG is the same env-var contract deploy.yml/ # deploy-prod.yml use against thermograph-infra's deploy.sh, so a dev-only # rollout never touches the frontend's running container or tag, exactly like # the beta/prod paths. on: push: branches: [dev] workflow_dispatch: {} jobs: build: name: build # Fixed (unparameterized) group, same convention as the deploy job's # below: if two pushes to dev land close together, the newer push's # build cancels the older's still-running one rather than letting both # run to completion on the single physical runner -- the older push's # result would just be thrown away once needs:build gates its deploy # against a stale build anyway. Safe to cancel mid-run: build.yml only # runs a throwaway `docker build` sanity check, nothing persisted. concurrency: group: dev-push-build cancel-in-progress: true uses: ./.forgejo/workflows/build.yml deploy: needs: build # NOT [self-hosted, thermograph-lan] -- that's what the original GitHub # version used, but GitHub implicitly tags every self-hosted runner with # "self-hosted" automatically; Forgejo's runner has only the labels it # was explicitly registered with ("docker" + "thermograph-lan", no # "self-hosted"). The array form silently makes this job unschedulable on # every push -- see the monorepo's deploy-dev.yml, which documents this # same bug against its own history. runs-on: thermograph-lan # Only needs to read the repo to fetch it into the checkout that computes # the tag below -- deploy-dev.sh itself lives in the separate INFRA # checkout on this host, not this repo's checkout. permissions: contents: read concurrency: group: dev-lan-deploy cancel-in-progress: false steps: - uses: actions/checkout@v4 - name: Compute image tag id: tag # Same 12-hex truncation deploy.yml/deploy-prod.yml use -- must match # build-push.yml's `sha-${GITHUB_SHA:0:12}` tag exactly (Actions # expressions have no substring function for the full 40-char SHA). run: echo "tag=sha-${GITHUB_SHA:0:12}" >> "$GITHUB_OUTPUT" - name: Deploy to the LAN dev server # thermograph-lan is host-native (the runner job runs directly on the # LAN box, not over SSH like beta/prod), so plain env vars on the # command reach deploy-dev.sh directly -- no ssh-action needed here. # # INERT until thermograph-lan is reprovisioned: deploy-dev.sh doesn't # exist yet at this path there (the box is currently a monorepo # checkout, not an infra checkout) -- see the file-level comment # above. Once reprovisioned, deploy-dev.sh self-updates via its own # `git reset` against thermograph-infra before running, the same way # deploy.sh/deploy-prod.sh already do for the beta/prod paths. run: SERVICE=backend BACKEND_IMAGE_TAG=${{ steps.tag.outputs.tag }} bash "$HOME/thermograph-dev/deploy/deploy-dev.sh"