[devinder-dev]

Step 1.5: the API pipeline in GitHub Actions (.github/workflows/api.yml).

What it does

• Every pull request: api-test installs with the frozen lockfile, then runs typecheck and bun test. api-image then checks that the Docker image builds for linux/amd64. Nothing is pushed.
• Every merge to main that touches api/: the same tests, then the image is built and pushed to GHCR as ghcr.io/devinder-dev/relay-api:<commit>. Deployment comes in step 1.8.

Choices

• No path filter on pull requests: api-test will be a required check, and a required check that never runs (for example on a dashboard-only PR) would block the merge forever. The API tests take about 30 seconds.
• Bun 1.4.4 from api/.bun-version: one file that CI reads and that documents the version for our laptops.
• Actions pinned to full commit SHAs, with the version as a comment, so a moved or hijacked tag can't run new code. docker/login-action is v4.6.0, because v4.7.0 was only 3 days old.
• Least privilege: contents: read by default. Only api-image gets packages: write, and it only logs in and pushes on main.
• Images are built on GitHub's amd64 runners, which match the VPS. Images built on a Mac would be arm64.
• concurrency cancels outdated PR runs. The gha cache reuses unchanged image layers.

After the first push to main

1. Make the GHCR package relay-api public, so k3s can pull it without credentials.
2. Add api-test as a required check in the protect-main ruleset.

Rebased onto main after #11 was merged, so it now contains only the workflow and api/.bun-version.

[AbdikhaniAbdirashid]

Approving this. It's small, the comments explain the why, and the two jobs do
exactly what the description says. A few things below — none of them blocking.

What I checked locally

• bun run typecheck exists in api/package.json (tsc --noEmit), api/bun.lock
  is committed, and api/Dockerfile really does take ARG GIT_SHA. So all three
  things the workflow calls are actually there.
• .bun-version is 1.4.4 and the Dockerfile base is oven/bun:1.4.4-slim. Same
  version in both places.
• I resolved all five pinned action SHAs against the GitHub tag API: checkout
  v7.0.1, setup-bun v2.2.0, setup-buildx v4.4.1, login v4.6.0, build-push v7.4.0.
  Every one matches its comment. Thanks for pinning these properly — a comment
  that doesn't match its SHA is how pinning quietly stops meaning anything.

Two small changes I'd like

1. timeout-minutes on both jobs. Without it a hung step runs to GitHub's 6-hour
   default and eats our Actions minutes. timeout-minutes: 10 on each would do.

2. api-image builds on every pull request, including dashboard-only ones. I
   follow the reasoning for api-test having no path filter — a required check
   that never runs blocks the merge forever — but the image build doesn't have
   that problem, since it won't be a required check. Right now every dashboard PR
   I open will build the API image for nothing. Is that deliberate, or worth a
   path filter / an if on the image job?

Three things to settle, not necessarily here

3. I looked at the protect-main ruleset: it has deletion, non_fast_forward
   and pull_request, but no required status checks at all yet. So the "api-test
   will be a required check" reasoning is about a future state. It's in your
   follow-up list — just flagging that until that's done, nothing is actually
   enforced.

4. Making the GHCR package public is a real decision and I don't think it should
   live only in a PR comment. A public image means anyone can pull and inspect our
   API. The alternative is an imagePullSecret in k3s: more setup, image stays
   private. I'm fine with public for this project, but can we put it in an ADR
   with that trade-off written down? We both have to defend it.

5. No Postgres service container here. That's correct today — the three test files
   are pure unit tests with no DB. But docs/CONTEXT.md says integration tests run
   against a real Postgres as a service container. When repositories land, does
   that go in this workflow, or a separate one? Asking so api-test doesn't get
   reopened later.

One question for me

6. On main, cancel-in-progress is false, so if two PRs merge a minute apart
   both runs finish and we get two images tagged with their own commit SHA. Is the
   intent that the deploy step in 1.8 always picks the newest SHA, or does the
   ordering of those two runs matter?

[devinder-dev]

Thanks for checking the SHAs against the tags yourself, that's exactly the check that keeps pinning meaningful. My answers:

1. timeout-minutes: agreed. infra: deploy every merge to main and check that it's live #16 already rewrites this file (as pipeline.yml), so I'm adding timeout-minutes: 10 to api-test and api-image there, rather than changing this PR and asking you to approve it again.

2. api-image on every PR: deliberate for now.

   • Actions minutes are free for public repositories on GitHub's standard runners, so the cost is time, not money.
   • With the build cache, an unchanged image builds in about 20 s.
   • One simple workflow is easier for both of us to explain than per-job path filters.
   • It also proves on every PR that the image still builds.
   • If CI gets slow once the dashboard image joins, we add an if on changed paths.

3. Required checks: right, nothing is enforced yet. I'll add api-test (and later the dashboard's test job) as required checks last, after infra: roll back to the last good commit and wait for every Deployment #14, infra: add the API manifests (2 pods, probes, zero-downtime rollout) #15 and infra: deploy every merge to main and check that it's live #16 are merged. Adding it now would mean updating every open branch and asking you to approve each one again.

4. Public image: good point, it's a real decision. I'll write it as ADR 0004 in its own small docs PR. Public means no pull secret to create, rotate or leak, and the code is public anyway. The cost is that anyone can pull and inspect the image, so it must never contain anything that isn't already in the repo. The alternative, a private package plus an imagePullSecret, would be written down there too.

5. Postgres in CI: in this same workflow. When the first repository lands (step 2.6), api-test gets a services: postgres container plus DATABASE_URL, so api-test stays the one required check for the API.

6. Two merges close together: the workflow-level concurrency group (<name>-${{ github.ref }}, never cancelling on main) runs main's pipelines one after the other, in merge order. Each deploys its own commit, so the newest merge always deploys last. If several merges wait, GitHub keeps only the newest pending run, and that commit already contains the others. On the server, relay-deploy's flock is a second layer. And its gate only accepts commits on main.

Merging this now as step 1 of the plan, then the image goes public (with ADR 0004 following).