CI: build-server/build-webapp do not run on pull requests, so compile errors only surface after merge #23

New issue

Open

opened 2026-08-05 01:09:25 +00:00 by mohlec · 0 comments

mohlec commented

2026-08-05 01:09:25 +00:00

Owner

Summary

build-server and build-webapp are triggered on pushes to slash/main, not on pull requests. Only branding-audit runs against a PR. This means a PR can be green and still not compile â€” the authoritative build happens after merge, when the bad commit is already on the main branch.

Evidence

Workflow runs from the 2026-08-04 upstream merge:

417 branding-audit  #22          success     <- the only check the PR got
418 build-webapp    #22          skipped
419 branding-audit  slash/main   running     <- real build starts only after merge
420 branding-audit  slash/main   running

Same pattern on PR #21 (run 411, build-webapp / #21 / skipped).

Why it matters now

The upstream merge in #22 changed 92 product files (+3,244/-310) across Go and TypeScript. That merged with no compile check in front of it. It happened to be fine, but the safety net was behind the merge rather than in front of it, and upstream merges are exactly the change class most likely to break a build.

This also interacts with a known gap: CI builds the webapp with webpack (transpileOnly), so type errors do not fail the build at all. There is already at least one latent tsc error on slash/main (theme_provider.tsx, TS2339 on the slash theme key).

Suggested fix

Add pull_request triggers for build-server and build-webapp in .forgejo/workflows/, targeting slash/main. Consider gating on paths so doc-only PRs stay cheap.

Optional follow-on: a non-blocking tsc --noEmit job, so type regressions are at least visible.

## Summary `build-server` and `build-webapp` are triggered on pushes to `slash/main`, not on pull requests. Only `branding-audit` runs against a PR. This means **a PR can be green and still not compile** â€” the authoritative build happens after merge, when the bad commit is already on the main branch. ## Evidence Workflow runs from the 2026-08-04 upstream merge: ``` 417 branding-audit #22 success <- the only check the PR got 418 build-webapp #22 skipped 419 branding-audit slash/main running <- real build starts only after merge 420 branding-audit slash/main running ``` Same pattern on PR #21 (run 411, `build-webapp` / `#21` / `skipped`). ## Why it matters now The upstream merge in #22 changed **92 product files** (+3,244/-310) across Go and TypeScript. That merged with no compile check in front of it. It happened to be fine, but the safety net was behind the merge rather than in front of it, and upstream merges are exactly the change class most likely to break a build. This also interacts with a known gap: CI builds the webapp with webpack (`transpileOnly`), so type errors do not fail the build at all. There is already at least one latent `tsc` error on `slash/main` (`theme_provider.tsx`, TS2339 on the `slash` theme key). ## Suggested fix Add `pull_request` triggers for `build-server` and `build-webapp` in `.forgejo/workflows/`, targeting `slash/main`. Consider gating on paths so doc-only PRs stay cheap. Optional follow-on: a non-blocking `tsc --noEmit` job, so type regressions are at least visible.

mohlec referenced this issue

2026-08-05 02:28:49 +00:00

fix(theme): cache-bust slash-theme.css so theme changes reach existing users #27

mohlec referenced this issue from a commit

2026-08-05 02:28:51 +00:00

fix(theme): cache-bust slash-theme.css so theme changes reach existing users

mohlec referenced this issue

2026-08-05 02:43:59 +00:00

slash-theme.css has no cache-busting and is served with a 1-year max-age, so theme fixes never reach existing users #26