pedro/DiveSim
1
0
Fork 0
Code Issues 74 Pull requests Projects Releases 1 Packages Wiki Activity Actions

Jessica CI worker available: second concurrent linux-x64-ci job #126

New issue
Open
opened 2026-11-02 00:50:10 +00:00 by pedro · 1 comment
pedro commented 2026-11-02 00:50:10 +00:00
Owner
Copy link

A second shared Forgejo CI worker, jessica-ci, is now available on the Kubernetes node Jessica. Together with paul-ci (#41), Pedro-owned projects now have two concurrent runs-on: linux-x64-ci jobs instead of one.

  • runs-on: linux-x64-ci (Ubuntu 24.04 Actions image) now runs on whichever of paul-ci / jessica-ci is free. Use runs-on: jessica-ci only when explicitly targeting Jessica.
  • jessica-ci carries only linux-x64-ci and jessica-ci. Jobs selecting divesim, track-pt3r (AdminiSync) or ansible-control (the-lair) keep their existing runners (their PVE1 runner plus paul-ci); to use the new slot, a job must select linux-x64-ci.
  • Same limits as paul-ci: 2 CPUs / 3 GiB RAM per job, 45-minute timeout, one job at a time per worker, disposable 16 GiB scratch. No persistent cache, GPU, host Docker socket, deployment credentials or Kubernetes API token.
  • Two linux-x64-ci jobs can now run at the same time, from the same or different repositories. The single slot no longer orders them implicitly: any job that deploys, publishes or writes shared state needs its own serialization (a concurrency: group or a deployment lock).
  • For trusted Pedro-owned projects only; keep public-fork approval gates. Independent checks split into separate jobs can now use both workers; steps inside one job still run sequentially.

Verified: smoke test run 574 passed on jessica-ci (checkout, PostgreSQL service networking, job limits, external TLS, no credential mounts), and pod.pt3r review run 248 on paul-ci overlapped matcher run 249 on jessica-ci.

Runbook: FORGEJO_RUNNERS.md · receipt: JESSICA_CI_ALLOCATION.md.

This is a resource-availability notice; no workflow or deployment behavior in this repository was changed by it.

A second shared Forgejo CI worker, `jessica-ci`, is now available on the Kubernetes node Jessica. Together with `paul-ci` (#41), Pedro-owned projects now have **two concurrent `runs-on: linux-x64-ci` jobs** instead of one. - `runs-on: linux-x64-ci` (Ubuntu 24.04 Actions image) now runs on whichever of `paul-ci` / `jessica-ci` is free. Use `runs-on: jessica-ci` only when explicitly targeting Jessica. - `jessica-ci` carries **only** `linux-x64-ci` and `jessica-ci`. Jobs selecting `divesim`, `track-pt3r` (AdminiSync) or `ansible-control` (the-lair) keep their existing runners (their PVE1 runner plus `paul-ci`); to use the new slot, a job must select `linux-x64-ci`. - Same limits as `paul-ci`: **2 CPUs / 3 GiB RAM** per job, **45-minute timeout**, one job at a time per worker, disposable 16 GiB scratch. No persistent cache, GPU, host Docker socket, deployment credentials or Kubernetes API token. - Two `linux-x64-ci` jobs can now run **at the same time**, from the same or different repositories. The single slot no longer orders them implicitly: any job that deploys, publishes or writes shared state needs its own serialization (a `concurrency:` group or a deployment lock). - For trusted Pedro-owned projects only; keep public-fork approval gates. Independent checks split into separate jobs can now use both workers; steps inside one job still run sequentially. Verified: [smoke test run 574](https://git.guresky.com/pedro/the-lair/actions/runs/574) passed on `jessica-ci` (checkout, PostgreSQL service networking, job limits, external TLS, no credential mounts), and pod.pt3r [review run 248](https://git.guresky.com/pedro/pod.pt3r/actions/runs/248) on `paul-ci` overlapped [matcher run 249](https://git.guresky.com/pedro/pod.pt3r/actions/runs/249) on `jessica-ci`. Runbook: [FORGEJO_RUNNERS.md](https://git.guresky.com/pedro/the-lair/src/branch/main/docs/FORGEJO_RUNNERS.md) · receipt: [JESSICA_CI_ALLOCATION.md](https://git.guresky.com/pedro/the-lair/src/branch/main/docs/JESSICA_CI_ALLOCATION.md). This is a resource-availability notice; no workflow or deployment behavior in this repository was changed by it.
pedro commented 2026-11-02 01:15:00 +00:00
Author
Owner
Copy link

Update (later on November 1, 2026): all Forgejo CI runners are now owner-scoped for pedro, and every runner accepts every shared label. This supersedes the label statements in the notice above.

  • Five concurrent job slots, one per runner: pve1-divesim, pve1-track-pt3r and pve1-ansible-control (LXC202 on pve1), paul-ci and jessica-ci.
  • Shared labels on all five: linux-x64-ci, divesim, track-pt3r and ansible-control. runs-on: linux-x64-ci is the recommended label for new workflows; paul-ci / jessica-ci pin a job to one Kubernetes worker.
  • Limits are unchanged: one job per runner, 2 CPUs / 3 GiB, 45 minutes.
  • Any job that deploys or writes shared state needs its own serialization, because free runners no longer queue it. Forgejo 12 does not honor YAML concurrency:, but it does cancel an older run of the same workflow, ref and trigger.

DiveSim: divesim jobs, including the Pages deploy, can now run on any of the five runners, and the Cloudflare secrets go to whichever runner takes the job. Forgejo 12 still cancels an older run of the same workflow, ref and trigger, so production deploys cannot overlap one another. Keep the fork-approval gate, since this repository is public.

Verified: five pod.pt3r workflows dispatched together ran simultaneously on all five runners (pod.pt3r runs 253–257). Receipt: CI_RUNNER_POOL.md. No workflow in this repository was changed.

**Update (later on November 1, 2026):** all Forgejo CI runners are now **owner-scoped** for `pedro`, and every runner accepts every shared label. This supersedes the label statements in the notice above. - Five concurrent job slots, one per runner: `pve1-divesim`, `pve1-track-pt3r` and `pve1-ansible-control` (LXC202 on pve1), `paul-ci` and `jessica-ci`. - Shared labels on all five: `linux-x64-ci`, `divesim`, `track-pt3r` and `ansible-control`. `runs-on: linux-x64-ci` is the recommended label for new workflows; `paul-ci` / `jessica-ci` pin a job to one Kubernetes worker. - Limits are unchanged: one job per runner, 2 CPUs / 3 GiB, 45 minutes. - Any job that deploys or writes shared state needs its own serialization, because free runners no longer queue it. Forgejo 12 does not honor YAML `concurrency:`, but it does cancel an older run of the same workflow, ref and trigger. **DiveSim:** `divesim` jobs, including the Pages deploy, can now run on any of the five runners, and the Cloudflare secrets go to whichever runner takes the job. Forgejo 12 still cancels an older run of the same workflow, ref and trigger, so production deploys cannot overlap one another. Keep the fork-approval gate, since this repository is public. Verified: five pod.pt3r workflows dispatched together ran simultaneously on all five runners (pod.pt3r runs 253–257). Receipt: [CI_RUNNER_POOL.md](https://git.guresky.com/pedro/the-lair/src/branch/main/docs/CI_RUNNER_POOL.md). No workflow in this repository was changed.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
t3/project-branding-style-guide
maintenance/review-2026-10-27
codex/release-r1
R1
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: pedro/DiveSim#126
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?