ci: consolidate workflows, build once per run #57
No Reviewers
Labels
Clear labels
Agentic
Component/CI
Component/Funnel
Component/React
Component/State
Component/Taildrive
Component/Taildrop
Component/Tailscale
Component/Tailshare
Component/Transport
Component/VFS
Component/WebRTC
Component/Worker
Human
Protocol/FTP
Protocol/HTTP
Protocol/SFTP
Protocol/SMB
Protocol/SSH
Protocol/WebDAV
Security
Agent
claude-fable-5
1
Work done by Claude Fable 5
Agent
claude-opus-4-8
2
Work done by Claude Opus 4.8
Agent
claude-opus-5
Work done by Claude Opus 5
Agent
claude-sonnet-4-6
3
Work done by Claude Sonnet 4.6
Agent
claude-sonnet-5
Work done by Claude Sonnet 5
Agent
gpt-5.5
7
Work done by GPT 5.5
Agent
gpt-5.6-luna
6
Work done by GPT 5.6 Luna
Agent
gpt-5.6-sol
4
Work done by GPT 5.6 Sol
Agent
gpt-5.6-terra
5
Work done by GPT 5.6 Terra
Opened by an agent
Work on the CI tooling
Work on the Tailscale Funnel or certificate system
Work on a React binding
Work on a state store (eg Redux)
Work on the taildrive system
Work on the taildrop system
Work on the Tailscale fork
Work on the Tailshare app
Work on the transport system
Work on the VFS system
Work on the WebRTC system
Work on the worker system
Opened by a human
Kind
Bug
Bug work
Kind
Enhancement
Enhancement work
Kind
Feature
Feature work
Kind
Maintenance
Maintenance work
Priority
P0
1
Critical work that must be done right now
Priority
P1
2
Urgent work
Priority
P2
3
Medium priority work
Priority
P3
4
Low priority work
Priority
P4
5
Lowest priority work, wishlist-tier
Work on the FTP protocol
Work on the HTTP protocol
Work on the SFTP protocol
Work on the SMB protocol
Work on the SSH protocol
Work on the WebDAV protocol
Security work
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: webnet/webnet#57
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
Every job in the old
checks.yml/test-node.yml/test-browser.ymlindependently repeated checkout + tailscale submodule clone +npm ci+ (for 5 of 7 jobs) a full Turbo build. There was no caching anywhere, which is most of why formatting checks took ~2 min and full test runs took up to 9.5 min.Live smoke tests against this Gitea instance (pushed as throwaway workflows, since removed) found:
actions/cache@v4(andsetup-node's built-incache: npm, same API) times out against the built-in cache proxy — a server-side issue, not fixable from workflow YAML.actions/upload-artifact@v4/download-artifact@v4refuse to run at all (GHES detection).actions/upload-artifact@v3/download-artifact@v3work correctly.So this consolidates the 3 workflow files into one
ci.yml:installdoes the real work once (submodule clone,npm ci, build) and handsnode_modules+ Turbo's cache off via v3 artifacts.typecheck/typetest/node-tests/browser-tests(needs: install) restore those artifacts instead of reinstalling/rebuilding from scratch.lint/formatnever touched the submodule or build output, so they drop that step and stay independent for fast feedback..gitea/actions/setup) instead of duplicated 7 times.concurrencygroup cancels superseded runs on the same ref.Also fixed along the way:
packages/xmlandpackages/vfspin a newer local TypeScript than the workspace root, installed by npm as nestedpackages/{xml,vfs}/node_modules/typescript. Theinstalljob'snode_modulesarchive now includes those per-package overrides, not just the root — the first version missed them and caused spurious typecheck failures in those two packages.Cross-run caching (reusing a previous run's install/build) isn't available until the Gitea cache backend is fixed server-side — that's a separate follow-up, not part of this PR. Someone with server access should check the
[actions]cache config inapp.iniand the runner'sACTIONS_CACHE_URL.Test plan
install,typecheck,typetest,node-tests,browser-tests,lint,formatall pass on this PRKnown unrelated flake observed during iteration: a pre-existing timing-sensitive test suite in
packages/tsconnect-worker/src/worker.test.tsoccasionally fails under load (different assertions each time); not caused by this change.Every job in the old checks.yml/test-node.yml/test-browser.yml independently repeated checkout + tailscale submodule clone + npm ci, and 5 of 7 also independently rebuilt the whole workspace via Turbo. There was no caching anywhere. Live smoke tests against this Gitea instance found actions/cache (and setup-node's built-in cache: npm, same API) times out against the built-in cache proxy - a server-side issue, not fixable from workflow YAML - and actions/upload-artifact/download-artifact v4 refuse to run at all (GHES detection). v3 of the artifact actions work correctly, so they're used as the handoff mechanism instead. .gitea/workflows/checks.yml, test-node.yml, and test-browser.yml are merged into one ci.yml. A new `install` job does the real work once (submodule clone, npm ci, build) and hands node_modules plus Turbo's local cache off via v3 artifacts to typecheck/typetest/node-tests/ browser-tests (all `needs: install`), instead of every job reinstalling and rebuilding from scratch. lint/format never touched the submodule or build output, so they drop that step and stay independent for fast feedback. The shared checkout+submodule+setup-node preamble is now a composite action, .gitea/actions/setup/action.yml (composite actions require the repo to already be checked out, so actions/checkout stays a separate first step in every job). A concurrency group cancels superseded runs on the same ref. The node_modules archive step must include per-package node_modules overrides, not just the root: packages/xml and packages/vfs pin a newer local TypeScript than the workspace root, installed by npm as nested packages/{xml,vfs}/node_modules/typescript. Missing those in the archive caused those two packages to silently typecheck against the wrong TypeScript version. Cross-run caching (reusing a previous run's install/build) isn't available until the Gitea instance's cache backend is fixed server-side - that's a separate, out-of-scope follow-up. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>93d6cb1c06to1aa26fd33e