syntaqxA workspace runs up to 12 jobs at once on g1t's machines while the pool has room, not 4. Every workspace was held to 4 hosted jobs at once (RUNNING_PER_WORKSPACE), so flagon-io's own CI and Deploy, about 13 jobs between them, waited their turn: 108 to 518 seconds after their runs were made, for 29aba25d, 58def404 and 0a5d1f6d, though the pool of 40 sandboxes (20 standard, 10 g1t-2core, 10 g1t-4core) was mostly idle. A workspace still always has its 4; past them, start_queued starts more, up to 12 (BURST_PER_WORKSPACE), while every workspace's hosted jobs together leave 8 sandboxes free (POOL_HEADROOM), so another workspace's first jobs still start at once (has_room). Deploy's own concurrency group still lands one deploy at a time. The architecture's Compute limits say so. Checked: cargo test -p g1t-actions-service (115 passing), npm run test:deploy (92).36c7309History
- ..
- anchors.yml
- artifacts.yml
- branches-ignore.yml
- cache.yml
- codeql.yml
- concurrency.yml
- container-job.yml
- defaults.yml
- dependabot-automerge.yml
- description-and-env.yml
- docker-action.yml
- docker-publish.yml
- environments.yml
- g1t-extension.yml
- go.yml
- if-expressions.yml
- issue-comment.yml
- java-gradle.yml
- job-options.yml
- labeler.yml
- many-events.yml
- matrix-from-json.yml
- max-parallel-expression.yml
- merge-queue.yml
- multiline-and-quotes.yml
- needs-outputs.yml
- node-matrix.yml
- on-null-events.yml
- pages.yml
- permissions-all.yml
- pr-review.yml
- pr-target-paths.yml
- publish-npm.yml
- python-package.yml
- release-on-tag.yml
- repository-dispatch.yml
- reusable-called.yml
- reusable-caller.yml
- runs-on-forms.yml
- rust-ci.yml
- sccache-like.yml
- schedule.yml
- services-postgres.yml
- single-event-string.yml
- stale.yml
- step-options.yml
- workflow-call-and-dispatch.yml
- workflow-dispatch-inputs.yml
- workflow-run.yml