Skip to content

fix(ci): pre-stage forge-CI memory caps for Phase 05e cutover#200

Merged
forkwright merged 1 commit intomainfrom
fix/kanon-ci-memory-caps
Apr 20, 2026
Merged

fix(ci): pre-stage forge-CI memory caps for Phase 05e cutover#200
forkwright merged 1 commit intomainfrom
fix/kanon-ci-memory-caps

Conversation

@forkwright
Copy link
Copy Markdown
Owner

Summary

Ships .kanon-ci.toml (copied verbatim from forkwright/kanon commit 1046068b) that caps cargo --jobs / --build-jobs / --test-threads to 8 so a full-workspace forge CI run stays under ~25GB peak RSS.

Without the caps, cargo defaults to num_cpus (64 on the menos Threadripper) and parallel rustc + nextest peak >100GB RSS, OOM-killing kanon-server.service — see ~/dianoia/inbox/2026-04-19-kanon-server-oom-cascade.md and forkwright/kanon#7.

Why now

harmonia is not yet cut over to forge-native PRs, so .kanon-ci.toml is a no-op today. Phase 05e will bring forge CI online for this repo — these caps must be in place before cutover or the first post-cutover push will OOM menos.

What

  • Add .kanon-ci.toml at repo root
  • Config copied verbatim from kanon's version (default Rust gate: fmt → check → clippy → nextest → lint)
  • No harmonia-specific divergence

Test plan

  • No-op until Phase 05e cutover — nothing to verify on GitHub CI
  • Post-cutover: first forge CI run stays under 25GB peak RSS

@forkwright forkwright force-pushed the fix/kanon-ci-memory-caps branch from 0911a5d to 47fc37e Compare April 19, 2026 17:20
forkwright pushed a commit that referenced this pull request Apr 19, 2026
sd-notify 0.5.0 changed notify() signature from
`notify(unset_env: bool, state: &[NotifyState])` to
`notify(state: &[NotifyState])`. Cargo.lock pins 0.5.0;
crates/archon/src/render/runner.rs still used the 2-arg form at
lines 13/17/25, breaking `cargo check` on the whole harmonia
workspace and consequently every kanon-gate-gated PR.

Three-line fix, no behavioral change: all three notify() calls
were passing unset_env=false, which is now the only supported
mode in 0.5.

Unblocks:
- PR #200 (forge-CI memory caps) — gate was failing on
  cargo check before reaching any lint stage
- PR #201 (forge→GitHub lint sync) — same
- Any future harmonia PR — gate can't run until this compiles
forkwright pushed a commit that referenced this pull request Apr 19, 2026
…errors

Blocks Phase 05e cutover arc — caps PR #200 and lint-sync PR #201 both
fail kanon gate on these pre-existing errors. Per operator directive
("pre-existing just means it's time to solve properly now"), fixing at
source rather than suppressing.

Changes:
- aitesis/repo.rs:132 update_status — extract `UpdateStatusParams<'a>`
  grouping (id, status, decided_by, decided_at, deny_reason, want_id).
  All 5 callers (approval.rs x2, lib.rs x2, repo.rs test x1) updated.
- komide/service/mod.rs:41 — remove unfulfilled
  `#[expect(clippy::type_complexity)]` on `cache_validators`; the
  `HashMap<String, (Option<String>, Option<String>)>` type no longer
  trips `clippy::type_complexity` (threshold changed under newer clippy
  in the 2025-11 lint-sync), so the expect is dead weight.
- zetesis/repo.rs:24 insert_indexer — extract
  `InsertIndexerParams<'a>` (name, url, protocol, api_key, cf_bypass,
  priority). Currently no callers inside the workspace; signature
  change is forward-compatible for future admin endpoints.
- paroche/subsonic/types.rs album_xml_elem / album_json — extract
  shared `AlbumElemParams<'a>` (id, name, artist, artist_id, year,
  song_count, duration). Marked `Copy` so call sites build the params
  once and pass to both encoders. All 3 call sites in lists.rs (x2) and
  browsing.rs (x1) updated accordingly.

Gate status on fix/clippy-too-many-args-post-lint-sync @ HEAD:
  PASS cargo fmt
  PASS cargo check
  PASS cargo clippy (all 5 target errors cleared)
  PASS cargo nextest
  FAIL kanon lint — 1 pre-existing SECURITY/insecure-transport
    violation at komide/service/mod.rs:572 (HTTP URL for podcast feed
    fetch); out of scope for this PR, unchanged by this diff.

Also reproduces the sd-notify 0.5 archon compile error under
`cargo clippy --workspace --all-features`; that's the separate
`fix/sd-notify-0.5` branch in flight.
forkwright pushed a commit that referenced this pull request Apr 19, 2026
Clears TOML/inline-table-too-long across:
- Cargo.toml (workspace, 4 sites)
- crates/paroche/Cargo.toml, crates/syndesis/Cargo.toml,
  crates/syndesmos/Cargo.toml, crates/theatron/desktop/Cargo.toml
- deny.toml (6 sites in [licenses] / [bans])

Pure reformatting — no semantic change to deps, features, or licenses.
Verified each site clears the lint individually.

Part of the harmonia 77-warning cleanup arc unblocking the
05e cutover gate chain (#200, #201, #202, #204).
forkwright added a commit that referenced this pull request Apr 20, 2026
Clears TOML/inline-table-too-long across:
- Cargo.toml (workspace, 4 sites)
- crates/paroche/Cargo.toml, crates/syndesis/Cargo.toml,
  crates/syndesmos/Cargo.toml, crates/theatron/desktop/Cargo.toml
- deny.toml (6 sites in [licenses] / [bans])

Pure reformatting — no semantic change to deps, features, or licenses.
Verified each site clears the lint individually.

Part of the harmonia 77-warning cleanup arc unblocking the
05e cutover gate chain (#200, #201, #202, #204).

Co-authored-by: Cody Kickertz <cody@forkwright.com>
forkwright pushed a commit that referenced this pull request Apr 20, 2026
…errors

Blocks Phase 05e cutover arc — caps PR #200 and lint-sync PR #201 both
fail kanon gate on these pre-existing errors. Per operator directive
("pre-existing just means it's time to solve properly now"), fixing at
source rather than suppressing.

Changes:
- aitesis/repo.rs:132 update_status — extract `UpdateStatusParams<'a>`
  grouping (id, status, decided_by, decided_at, deny_reason, want_id).
  All 5 callers (approval.rs x2, lib.rs x2, repo.rs test x1) updated.
- komide/service/mod.rs:41 — remove unfulfilled
  `#[expect(clippy::type_complexity)]` on `cache_validators`; the
  `HashMap<String, (Option<String>, Option<String>)>` type no longer
  trips `clippy::type_complexity` (threshold changed under newer clippy
  in the 2025-11 lint-sync), so the expect is dead weight.
- zetesis/repo.rs:24 insert_indexer — extract
  `InsertIndexerParams<'a>` (name, url, protocol, api_key, cf_bypass,
  priority). Currently no callers inside the workspace; signature
  change is forward-compatible for future admin endpoints.
- paroche/subsonic/types.rs album_xml_elem / album_json — extract
  shared `AlbumElemParams<'a>` (id, name, artist, artist_id, year,
  song_count, duration). Marked `Copy` so call sites build the params
  once and pass to both encoders. All 3 call sites in lists.rs (x2) and
  browsing.rs (x1) updated accordingly.

Gate status on fix/clippy-too-many-args-post-lint-sync @ HEAD:
  PASS cargo fmt
  PASS cargo check
  PASS cargo clippy (all 5 target errors cleared)
  PASS cargo nextest
  FAIL kanon lint — 1 pre-existing SECURITY/insecure-transport
    violation at komide/service/mod.rs:572 (HTTP URL for podcast feed
    fetch); out of scope for this PR, unchanged by this diff.

Also reproduces the sd-notify 0.5 archon compile error under
`cargo clippy --workspace --all-features`; that's the separate
`fix/sd-notify-0.5` branch in flight.

Gate-Passed: kanon 0.1.0
forkwright added a commit that referenced this pull request Apr 20, 2026
…errors (#204)

Blocks Phase 05e cutover arc — caps PR #200 and lint-sync PR #201 both
fail kanon gate on these pre-existing errors. Per operator directive
("pre-existing just means it's time to solve properly now"), fixing at
source rather than suppressing.

Changes:
- aitesis/repo.rs:132 update_status — extract `UpdateStatusParams<'a>`
  grouping (id, status, decided_by, decided_at, deny_reason, want_id).
  All 5 callers (approval.rs x2, lib.rs x2, repo.rs test x1) updated.
- komide/service/mod.rs:41 — remove unfulfilled
  `#[expect(clippy::type_complexity)]` on `cache_validators`; the
  `HashMap<String, (Option<String>, Option<String>)>` type no longer
  trips `clippy::type_complexity` (threshold changed under newer clippy
  in the 2025-11 lint-sync), so the expect is dead weight.
- zetesis/repo.rs:24 insert_indexer — extract
  `InsertIndexerParams<'a>` (name, url, protocol, api_key, cf_bypass,
  priority). Currently no callers inside the workspace; signature
  change is forward-compatible for future admin endpoints.
- paroche/subsonic/types.rs album_xml_elem / album_json — extract
  shared `AlbumElemParams<'a>` (id, name, artist, artist_id, year,
  song_count, duration). Marked `Copy` so call sites build the params
  once and pass to both encoders. All 3 call sites in lists.rs (x2) and
  browsing.rs (x1) updated accordingly.

Gate status on fix/clippy-too-many-args-post-lint-sync @ HEAD:
  PASS cargo fmt
  PASS cargo check
  PASS cargo clippy (all 5 target errors cleared)
  PASS cargo nextest
  FAIL kanon lint — 1 pre-existing SECURITY/insecure-transport
    violation at komide/service/mod.rs:572 (HTTP URL for podcast feed
    fetch); out of scope for this PR, unchanged by this diff.

Also reproduces the sd-notify 0.5 archon compile error under
`cargo clippy --workspace --all-features`; that's the separate
`fix/sd-notify-0.5` branch in flight.

Gate-Passed: kanon 0.1.0

Co-authored-by: Cody Kickertz <cody@forkwright.com>
forkwright pushed a commit that referenced this pull request Apr 20, 2026
sd-notify 0.5.0 changed notify() signature from
`notify(unset_env: bool, state: &[NotifyState])` to
`notify(state: &[NotifyState])`. Cargo.lock pins 0.5.0;
crates/archon/src/render/runner.rs still used the 2-arg form at
lines 13/17/25, breaking `cargo check` on the whole harmonia
workspace and consequently every kanon-gate-gated PR.

Three-line fix, no behavioral change: all three notify() calls
were passing unset_env=false, which is now the only supported
mode in 0.5.

Unblocks:
- PR #200 (forge-CI memory caps) — gate was failing on
  cargo check before reaching any lint stage
- PR #201 (forge→GitHub lint sync) — same
- Any future harmonia PR — gate can't run until this compiles

Gate-Passed: kanon 0.1.0
forkwright added a commit that referenced this pull request Apr 20, 2026
…202)

sd-notify 0.5.0 changed notify() signature from
`notify(unset_env: bool, state: &[NotifyState])` to
`notify(state: &[NotifyState])`. Cargo.lock pins 0.5.0;
crates/archon/src/render/runner.rs still used the 2-arg form at
lines 13/17/25, breaking `cargo check` on the whole harmonia
workspace and consequently every kanon-gate-gated PR.

Three-line fix, no behavioral change: all three notify() calls
were passing unset_env=false, which is now the only supported
mode in 0.5.

Unblocks:
- PR #200 (forge-CI memory caps) — gate was failing on
  cargo check before reaching any lint stage
- PR #201 (forge→GitHub lint sync) — same
- Any future harmonia PR — gate can't run until this compiles

Gate-Passed: kanon 0.1.0

Co-authored-by: Cody Kickertz <cody@forkwright.com>
Ship the same .kanon-ci.toml that landed in forkwright/kanon as commit
1046068b ("fix(ci,stoa): cap CI concurrency + stop env-leaking
embedding into tests") — caps cargo --jobs / --build-jobs /
--test-threads to 8 so a full-workspace forge CI run stays under
~25GB peak RSS instead of peaking over 100GB and OOM-killing
kanon-server.service.

Why now: this repo is not yet cut over to forge-native PRs, so
.kanon-ci.toml is a no-op until Phase 05e brings forge CI online
for forkwright/harmonia. Staging the caps ahead of cutover avoids
the first post-cutover push OOMing menos (see dianoia inbox note
2026-04-19-kanon-server-oom-cascade.md and kanon#7).

Config is copied verbatim from kanon's version — default Rust gate
(fmt → check → clippy → nextest → lint), concurrency capped at 8
per stage, no harmonia-specific divergence.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Gate-Passed: kanon 0.1.0
@forkwright forkwright force-pushed the fix/kanon-ci-memory-caps branch from 47fc37e to 0ec4612 Compare April 20, 2026 13:09
@forkwright forkwright merged commit b9fb1bc into main Apr 20, 2026
3 checks passed
@forkwright forkwright deleted the fix/kanon-ci-memory-caps branch April 20, 2026 13:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant