mirror of
https://github.com/rennf93/roboco.git
synced 2026-08-03 07:23:24 +02:00
42f8a5d18e
* fix(board): give Board Program explorers a nothing_to_propose exit Every propose_* verb requires at least one item, so an explorer that legitimately found nothing — Barfly with no worthwhile X conversations, Coroner with no autopsy subject — had no way to close its exploration task. It declined, called i_am_idle(), and the task stayed PENDING forever: the dispatcher re-matched it every tick and respawned the board agent (~$0.61 a spawn, ~3 per 5-minute respawn-breaker cooldown window, indefinitely), and BoardProgramEngine's one-open-cycle dedup wedged that whole program shut, since the ledger row only closes once its exploration task goes terminal. nothing_to_propose(task_id, reason) is the explicit exit. task_id is required rather than inferred: one explorer role owns several independently-cadenced programs (head_marketing owns six) and each assigns its exploration task to the same agent, so several are open at once by design and guessing "the caller's oldest" completes the WRONG cycle — stamping its reason onto an unrelated program's ledger while the task actually being worked stays wedged. Resolution validates the named task exists, carries a registered program source, is assigned to the caller, and is non-terminal, then gates on the program's declared explorer role from the registry, so a program registered later needs no edit here. The reason lands on board_program_cycles (migration 089) and renders into the next cycle's LEARN context, replacing a bare "proposed 0, approved 0" with why. That write runs in its own savepoint: it flushes on the same session as the completion, and a bare try/except around a same-session flush leaves the transaction pending-rollback, so a DB blip there would discard the completion at the post-response commit while the verb reported success. All fourteen exploration prompts offer the exit, pinned by a registry-parametrized test that fails when a future program is unwired. * ci: fire PR checks on slave-based PRs, not master alone All five gating workflows declared `pull_request: branches: [master]`, but every fleet PR targets slave — cell->root, root->slave, and the CEO's own. So `pull_request` never fired for any of them, and their only coverage was the `push` trigger, which is gated on branch PREFIX (feature/bug/chore/docs/hotfix). A branch named anything else got zero checks — not a red run, an absent one — and a PR with no required check present merges on a false green. PR #711 shipped that way on a `fix/` branch. Basing on the branch a PR merges INTO rather than what its head is named makes coverage independent of branch naming, so a non-conforming prefix can only ever cost the redundant push run, never the whole gate. The same five also omitted slave from `push` (ci.yml aside, which added it for the release gate's fail-closed CI read), so the panel suite, both CodeQL analyses, and the e2e smoke never ran on the trunk master is cut from. --------- Co-authored-by: Renn F <rennf93@users.noreply.github.com>
86 lines
2.7 KiB
YAML
86 lines
2.7 KiB
YAML
name: Panel CI
|
|
|
|
on:
|
|
push:
|
|
branches:
|
|
- master
|
|
# The dev branch: every fleet PR merges here, so without it the panel
|
|
# suite never ran on the trunk that master is cut from.
|
|
- slave
|
|
# Fleet task branches: `pull_request`'s synchronize trigger doesn't
|
|
# reliably fire when a revision lands on a PR head via the merge API
|
|
# (see ci.yml for the live-proven receipts); `push` does.
|
|
- 'feature/**'
|
|
- 'bug/**'
|
|
- 'chore/**'
|
|
- 'docs/**'
|
|
- 'hotfix/**'
|
|
paths:
|
|
- 'panel/**'
|
|
- '.github/workflows/panel-ci.yml'
|
|
pull_request:
|
|
branches:
|
|
- master
|
|
# Fleet PRs target the dev branch — see ci.yml's pull_request note.
|
|
- slave
|
|
paths:
|
|
- 'panel/**'
|
|
- '.github/workflows/panel-ci.yml'
|
|
workflow_dispatch:
|
|
|
|
# A fleet branch that's also an open PR head can get both a `push` and a
|
|
# `pull_request` run for the same commit; cancel the older one instead of
|
|
# burning two runners on identical work. `head_ref` (set only for
|
|
# pull_request) and `ref_name` (the short branch name, valid for push) both
|
|
# resolve to the SAME branch name, so the two event shapes share one group —
|
|
# plain `github.ref` would NOT (it's `refs/pull/<n>/merge` for pull_request
|
|
# vs `refs/heads/<branch>` for push, so it'd never collapse them).
|
|
concurrency:
|
|
group: ${{ github.workflow }}-${{ github.head_ref || github.ref_name }}
|
|
cancel-in-progress: true
|
|
|
|
jobs:
|
|
panel:
|
|
name: Panel (Next.js)
|
|
runs-on: ubuntu-latest
|
|
|
|
defaults:
|
|
run:
|
|
working-directory: panel
|
|
|
|
steps:
|
|
- name: Checkout code
|
|
uses: actions/checkout@v7
|
|
with:
|
|
# The release-readiness smoke test calls ``git describe --tags`` to
|
|
# find the most recent release tag. ``actions/checkout``'s default
|
|
# shallow + no-tags clone makes that return empty, which made
|
|
# ``test_gather_snapshot_reads_the_real_repo`` fail with
|
|
# ``last_tag is None`` even though master had a tagged v0.13.0.
|
|
# ``fetch-depth: 0`` clones full history; the default ``fetch-tags``
|
|
# would still skip tags on shallow clones, so we also pin it true.
|
|
fetch-depth: 0
|
|
fetch-tags: true
|
|
|
|
- name: Set up Node
|
|
uses: actions/setup-node@v7
|
|
with:
|
|
# pnpm 11 (pinned in panel/package.json via packageManager) requires
|
|
# Node >=22.13; Node 20 makes `pnpm install` fail the engines check.
|
|
node-version: '22'
|
|
|
|
- name: Enable corepack (pnpm)
|
|
run: corepack enable
|
|
|
|
- name: Install dependencies
|
|
run: pnpm install --frozen-lockfile
|
|
|
|
- name: Lint
|
|
run: pnpm lint
|
|
|
|
- name: Type-check
|
|
run: pnpm exec tsc --noEmit
|
|
|
|
- name: Test (vitest + coverage)
|
|
run: pnpm test
|