Skip to content

Conversation

erikhfj
Copy link
Member

@erikhfj erikhfj commented Sep 28, 2026

What this does

Gets the CI workflow onto main. It has been missing entirely.

How that happened: PR #34 had base feat/1-repo-tooling because it was stacked on #32. #32 merged feat/1-repo-tooling into main at 17:11, then #34 merged into feat/1-repo-tooling at 17:28. By then that branch was no longer feeding main, so the workflow landed on a dead-end branch. main has only ever had CODEOWNERS under .github/.

So every PR opened since then, including #33, #35 and #36, has had no CI at all. Worth knowing when you review those.

What is in the file

Unchanged from what #34 reviewed:

  • quality on every PR and every push to main: pnpm install --frozen-lockfile, then format:check, lint, typecheck, test, build, then a client bundle budget of 512 kB per JS chunk.
  • deploy on push to main only: builds and publishes client/dist to /var/www/html/project2, curls it to confirm it served, and restarts crate-api only if that systemd unit exists. So it works today at M1 and still works in M2.

Two fixes that came out of running it

1. pull_request no longer filters on branches: [main]. A stacked PR like #34 targets a branch, so the filter silently produced zero workflow runs. I noticed only because my push produced no run at all. We stack PRs, so a branch filter is wrong here.

2. deploy is pinned to [self-hosted, linux, x64, project2]. Rachel spotted that the project2 label was never used in runs-on. She was right. deploy writes to /var/www/html/project2 and restarts crate-api, which only exist on it2810-19, so it must not land on a different machine if a second runner is ever added. quality stays unpinned on purpose since it is a pure function of the tree.

What was tested

Closes

Closes #27.

The workflow is on main for the first time. PR #34 merged into
feat/1-repo-tooling (its base at the time) after #32 had already merged
that branch into main, so the workflow never reached main and the repo
has been running with no CI at all. This brings it across.

Content is unchanged from what #34 reviewed and what has been passing on
the runner: quality job (format, lint, typecheck, test, build, bundle
budget) on every PR and every push to main, deploy job on push to main
only.

Two fixes that came out of actually running it:

- pull_request has no branch filter. A `branches: [main]` filter meant
  stacked PRs like #34, which targets feat/1-repo-tooling, silently got
  zero CI runs.

- deploy is pinned to [self-hosted, linux, x64, project2]. It writes to
  /var/www/html/project2 and restarts crate-api, which only exist on
  it2810-19. quality stays unpinned so any future runner can pick it up.

Co-Authored-By: opencode <noreply@opencode.ai>
@erikhfj erikhfj requested a review from a team as a code owner September 28, 2026 20:47
Copy link
Member

@rachelks rachelks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good now! Sorry about the mix-up with the stacked PRs earlier. Approved

@rachelks rachelks merged commit 498f024 into main Sep 29, 2026
2 checks passed
@rachelks rachelks deleted the chore/27-ci-on-main branch October 15, 2026 08:30
Sign in to join this conversation on GitHub.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CI/CD pipeline on the self-hosted runner
2 participants