align every deploy workflow with inventory's .github/workflows/deploy.yml
#14
brendan
commented
Owner
> **Originally filed:** 2026-05-09 in ~/bugs.md, block #12.
> **Cross-project companion issues:** brendan/authd, brendan/buchinese, brendan/movement
<!-- Resolved 2026-05-10 — PR https://gitea.bchen.dev/brendan/nanodrop/pulls/5 (merge_commit bee3cd2e987df61360a45f51bfe04beb120fb3ea) — final bullet (nanodrop) closed; all four projects (authd, movement, buchinese, nanodrop) now aligned with ~/inventory/.github/workflows/deploy.yml.
**2026-05-09 — cross-project: align every deploy workflow with inventory's `.github/workflows/deploy.yml`; the only allowed per-project delta is the env-var block**
> **Progress (updated 2026-05-10):** authd ✅ done (PR #10). buchinese ✅ effectively done — user manually aligned the workflow on `origin/main` (commits `4af6cc4`, `70465d0`, `e6d1b1c`, `d57dc40`, `1f8db69`); single remaining delta is the file path (`.gitea/workflows/` instead of `.github/workflows/`), which is functionally equivalent on Gitea Actions and intentionally left in place. movement ✅ done 2026-05-10 (PR #14, merge_commit `37aef27f6e659913a65393fd7e93ac71fc8f3400`). nanodrop ✅ done 2026-05-10 (PR #5, merge_commit `bee3cd2e987df61360a45f51bfe04beb120fb3ea`). All four projects aligned.
User directive (spawn-host, 2026-05-09): "For any project that has a different deployment workflow compared to the inventory project, that project's deploy workflow should be updated to match that of the inventory. The only difference should be the environment variables. But, otherwise, it should be the same workflow verbatim."
**Canonical workflow:** `~/inventory/.github/workflows/deploy.yml` (66 lines). Key shape, in order:
1. `name: "Deploy to birb co. production"`
2. Triggers: `push.branches: [main]` + `workflow_dispatch:`
3. `runs-on: ubuntu-latest`
4. Steps: `Check out repository` (`actions/checkout@v3`) → `Validate required secrets` (uses `set -euo pipefail` and `: "${VAR:?msg}"` per required secret/var, with the same vars exported into the step's `env:` block) → `Set up SSH key` (writes `~/.ssh/id_ed25519`, `chmod 600`, `ssh-keyscan ${{ vars.HOST }}`) → `Remove directory from server` (`ssh ... rm -rf ~/${{ vars.DIRECTORY_NAME }}`) → `Transfer repository files to server` (`scp -r ./* …:~/${{ vars.DIRECTORY_NAME }}`) → `Deploy on server with Docker` (heredoc that `cd`'s into the dir, `export`s each secret/var, then `docker compose -f compose.yaml down && docker compose -f compose.yaml up -d --build`).
5. Variable-naming convention: GitHub Actions `vars.HOST`, `vars.USERNAME`, `vars.DIRECTORY_NAME`, `vars.PORT`, `vars.BASE_URL`; secrets via `secrets.SSH_PRIVATE_KEY` + project-specific app secrets.
6. Compose file referenced as `compose.yaml` (not `docker-compose.yml`).
**Projects to update (with the per-project deltas observed today):**
- ~~`~/authd/.github/workflows/deploy.yml`~~ — **DONE 2026-05-10** in PR https://gitea.bchen.dev/brendan/authd/pulls/10 (merge_commit `c37f2829bed5dd28a60837ff7970c8773b5a5f0e`). Validate step added (secrets only — `SSH_PRIVATE_KEY`, `JWT_SECRET`, `MFA_ENC_KEY` — matching inventory's pattern; `PORT`/`BASE_URL` are vars and inventory doesn't validate vars). Heredoc terminator aligned with inventory (`<< 'EOF'` → `<< EOF`); export values single-quoted. Diff against `~/inventory/.github/workflows/deploy.yml` is now confined to env-var content. Needs manual deploy verification by the user post-merge.
- ~~`~/movement/.github/workflows/deploy.yml`~~ — **DONE 2026-05-10** in PR https://gitea.bchen.dev/brendan/movement/pulls/14 (merge_commit `37aef27f6e659913a65393fd7e93ac71fc8f3400`). Validate step added for `SSH_PRIVATE_KEY`, `JWT_SECRET`, `MAPKIT_JS_TOKEN`, `MAPKIT_KEY_ID`, `MAPKIT_TEAM_ID` (matching inventory's secrets-only validation pattern; `PORT` is a var, not validated, per the authd precedent). Heredoc terminator aligned (`<< 'EOF'` → `<< EOF`); export values single-quoted; export order matches inventory (secrets first, `PORT` last). `PUBLICLY_AVAILABLE` intentionally not added — `compose.yaml`'s `x-env` anchor doesn't include it, so the deploy export alone would be a no-op; making it deploy-controllable would require also editing `compose.yaml` (out of scope per "Do not change compose-file *contents*"). Current `PUBLICLY_AVAILABLE=false` (locked-down) default preserved. Diff confined to `.github/workflows/deploy.yml`. Needs manual deploy verification by the user post-merge.
- `~/nanodrop/.github/workflows/deploy-homelab.yml` — Three structural deltas:
1. Filename is `deploy-homelab.yml`; canonical is `deploy.yml`. Rename to `deploy.yml`.
2. Workflow `name:` is `"Deploy to Homelab"`; canonical is `"Deploy to birb co. production"`. **Decision needed** — the user said "verbatim except env vars", which would mean changing the name to match. But the name is documentation, not behavior. Default to renaming to match; if the bug-fixer thinks a project-specific name is preferable, leave a one-line note in the PR explaining the deviation.
3. Compose file referenced as `docker-compose.yml`; canonical is `compose.yaml`. The repo has `docker-compose.yml` on disk — either rename it on disk to `compose.yaml` (Docker Compose v2 reads either, so both filenames work locally) **or** keep the disk filename and accept this one structural deviation in the workflow. Default: rename the disk file to `compose.yaml` so the workflow truly matches verbatim.
4. Missing the validate step. Env-var block: `TRUST_PROXY`, `COOKIE_SECURE`, `JWT_SECRET`, `PORT`, `BASE_URL`, `MAX_FILE_SIZE`. Note that `TRUST_PROXY=true` and `COOKIE_SECURE=true` are hardcoded literals in the heredoc, not pulled from `vars.*`/`secrets.*` — keep them as hardcoded literals (they're env values, not secrets) since the directive says env-var content can differ.
- ~~`~/buchinese/.gitea/workflows/deploy.yml`~~ — **DONE 2026-05-10** via direct user commits to `origin/main` (`4af6cc4` "Update variables to be consistent with other projects", `70465d0` "Enable auto-deploy", `e6d1b1c` "Replace workflow with one from another project", `d57dc40`, `1f8db69`). Re-survey 2026-05-10 confirmed the workflow now matches `~/inventory/.github/workflows/deploy.yml` line-by-line: same name, push+workflow_dispatch triggers, validate-secrets step (with the inventory secret list — `SSH_PRIVATE_KEY`, `SESSION_ENC_KEY`, `AUTHD_*` — plus extra `SSH_HOST`/`SSH_USER`/`DEPLOY_DIR` var validations aliased through the env block, which is an additive enhancement not a regression), `id_ed25519` SSH key, `vars.HOST`/`vars.USERNAME`/`vars.DIRECTORY_NAME` naming, `scp -r ./*` transfer, `<< EOF` heredoc with `export` lines and `compose down`+`up` against `compose.yaml`. Allowed env-var deltas: deploy heredoc has `ANTHROPIC_API_KEY` (and no `BASE_URL`) where inventory has `BASE_URL` (and no `ANTHROPIC_API_KEY`) — both within the env-block carve-out. **Single remaining structural delta:** workflow path is `.gitea/workflows/` not `.github/workflows/`. Gitea Actions reads both paths so this is functionally a no-op; treating it as a deliberate non-issue rather than chasing a cosmetic move. If the user wants the path normalized, file a separate one-line follow-up. Needs manual deploy verification by the user post-merge of any related work, but no bug-fixer action is required for this bullet.
**Optional follow-up (not required for this bullet):** consider backporting buchinese's extra var-validation entries (`SSH_HOST`/`SSH_USER`/`DEPLOY_DIR`) into inventory's validate-secrets step so prod deploys fail-fast when a Gitea/GitHub repo var is unset. File separately if wanted.
**Excluded from this chore (no production deployment exists):** `~/dashcam`, `~/portman`, `~/tradebot` — none have any workflow file under `.github/workflows/` or `.gitea/workflows/`. Do **not** add a deploy workflow to these as part of this chore; if/when they need one, file a separate item.
**Approach (recommended PR sequencing):**
1. **PR per project** (four PRs total: authd, movement, nanodrop, buchinese). Keep them independent so each can be reviewed and rolled back individually if a deploy regresses.
2. Within each PR, keep the diff to *only* the workflow file (and, for nanodrop, the `compose.yaml` rename). Do **not** bundle in unrelated cleanups — the user has been explicit before that umbrella PRs are harder to review and revert.
3. For each PR, before merging, eyeball the rendered workflow against `~/inventory/.github/workflows/deploy.yml` line-by-line — the only allowed deltas are: (a) the env-var block contents, (b) for buchinese, the trigger if the user opts to keep it `workflow_dispatch`-only, (c) for buchinese, the Gitea vars step if names can't be renamed.
4. **Do not test by triggering a real deploy.** The bug-fixer doesn't have access to flip production. Leave the smoke test to the user post-merge — note in each PR description "needs manual deploy verification by user".
5. Branch prefix: `chore/` (not `feat/`) per global rule for cross-project consistency refactors.
**Acceptance:**
- All four PRs land on `main` in their respective repos via the standard bug-fixer auto-merge pipeline (sync-from-main precondition, mergeable check, no SHA pin per `~/CLAUDE.md` `tea pr merge` notes).
- Diffing any non-inventory project's `deploy.yml` against `~/inventory/.github/workflows/deploy.yml` yields differences confined to: the env-var list (validate step + `export` lines in the deploy step), and — only if the user explicitly approves keeping them — buchinese's trigger and Gitea var names.
- For nanodrop: the disk file is `compose.yaml` (renamed from `docker-compose.yml`), the workflow file is `deploy.yml` (renamed from `deploy-homelab.yml`), and no other repo file references the old names.
- No deploy workflow is added to dashcam/portman/tradebot.
**Out-of-scope notes for the bug-fixer:**
- Do not modify the inventory deploy workflow itself — it's the reference. If the bug-fixer notices a real bug in inventory's workflow during this work, file it as a separate item in `~/bugs.md`.
- Do not change Dockerfiles, compose-file *contents*, env defaults, or any application-level config as part of this chore. Workflow file only (plus the nanodrop compose-filename rename, which is the single allowed structural change).
- Two ambiguities (buchinese trigger, nanodrop name field) need a quick yes/no from the user before merging — if the bug-fixer can't get a fast answer, ship the most conservative interpretation (keep buchinese `workflow_dispatch`-only with a comment; rename nanodrop's workflow `name:` field to match canonical) and flag both decisions in the PR description so the user can ask for a follow-up if they disagree.
Source: user via spawn-host (2026-05-09). Confirmed by direct read of the five existing deploy workflow files and the absence of workflow files in dashcam/portman/tradebot. No prior dedupe collision in `~/bugs.md` or `~/features.md` — the closest existing item, the (now-superseded) movement-port chore, is a project-internal pattern port and does not address cross-project deploy alignment.
-->
brendan
added the bug label
brendan
closed this issue
brendan
referenced this issue
extract authd's SQLite migration system into a standalone npm package #16
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?