[ten9876]

Fixes #6130

Problem

CodeQL / analyze (cpp) has failed on every push to main since 2026-10-02 21:52 UTC with No space left on device in the Build step, so no C++ code-scanning results have been uploaded since. The workflow builds every default target as RelWithDebInfo. With -g, each of the ~250 test executables that link a static aethercore comes to roughly 317 MB.

Fix

In .github/workflows/codeql.yml, configure with -DCMAKE_BUILD_TYPE=Release. CodeQL extracts from the compiler invocations and never uses debug info, so nothing it analyzes changes. The set of built targets is unchanged.

The workflow also gains a workflow_dispatch trigger, so a codeql.yml change can be run on its branch before it merges.

Validation

Measured locally (Linux, same tree):

	RelWithDebInfo	Release
libaethercore.a	489 MB	56 MB
a test executable	~317 MB	~29 MB average
whole build tree	(doesn't fit the runner, ~83 GB free)	19 GB (594 tests, 17 GB)

A full Release build of every default target completes cleanly (11 min, 16 jobs).

On the runner: branch run 37172958567, dispatched with the new trigger on this head, runs Configure → Build → CodeQL analysis → upload. The first push-to-main run re-checks it after merge.

🤖 Generated with Claude Code

[aethersdr-agent]

Issue fit

Yes. #6130 is "every main push dies in the Build step with No space left on device, root cause = every default target built with -g, each test executable statically linking aethercore." The one-line build-type change removes -g from the whole tree and nothing else, which attacks exactly the named cause. The acceptance condition ("C++ code-scanning results upload again for main") can only be observed post-merge, and the body says so plainly rather than claiming validation it doesn't have — that's the honest form of Principle VIII here, not a gap.

No test is requestable for this: a workflow build-type change has no deterministic seam in the test graph, and tools/check_qt_pin.py-style static checks don't cover build types. Not a nit, just not testable.

Scope

File	Change	Claimed by title/body?	Verdict
.github/workflows/codeql.yml (L107–112)	RelWithDebInfo → Release + 4-line why comment	Yes	In scope

Everything in the diff is explained by the issue. Single file, single functional line, no CHANGELOG.md entry (correct), no new public surface, no deleted guard — the removed line is the build type itself and the comment that replaces it names the symptom it prevents. No sibling workflow to update: codeql.yml is the only file referencing codeql-action, and the Analyze (javascript-typescript) / Analyze (python) checks on this SHA come from GitHub default setup, not from a workflow file, so C++ is scanned only here.

Blockers

None.

Nits (non-blocking)

• The committed comment's "~4x" contradicts the PR's own measurements (317 MB → 29 MB is ~11x; libaethercore.a 489 → 56 MB is ~8.7x). Inline suggestion below, since the comment outlives the PR body.
• "each links its own static aethercore" over-counts. CMakeLists.txt:~80 says "~124 test targets that link aethercore"; the body generalizes the ~317 MB figure to all ~600. 594 × 317 MB ≈ 188 GB, which couldn't have been the tree that was still green on 10-02 05:26 under the same build type — so the per-executable figure plainly belongs to the aethercore-linking subset. Doesn't touch the fix (the measured Release total of 19 GB is what carries it), but worth not freezing into a comment.
• No workflow_dispatch. It can't help this PR (dispatch only works once the trigger is on the default branch), but adding it would let the next person validate a codeql.yml change before merging instead of after. Optional, and arguably its own PR.
• The precedent cited in #6130 doesn't appear to exist. The issue calls this "the same disk-exhaustion pattern the ASan sanitizer lane hit," but sanitizers.yml carries no mitigation I can find — no --target subset, no strip, no -g1/-gsplit-dwarf; it builds the full default graph at Debug/RelWithDebInfo with tree-wide -g3 added on top (sanitizers.yml:124,142). So there was no sibling solution to mirror, and those lanes remain exposed to the same growth. Not this PR's job — flagging so the phrase isn't read as "the fix is already known elsewhere."

What I tried to break

All findings below are reasoned from the head checkout at /tmp/aetherclaude/pr-6135; I ran no build and no CodeQL run.

• "Nothing it analyzes changes" — the strongest attack is NDEBUG flipping extraction coverage. It doesn't: CMake's defaults are -O2 -g -DNDEBUG for RelWithDebInfo and -O3 -DNDEBUG for Release, so NDEBUG is defined either way and no #ifndef NDEBUG region changes visibility. Independently, a grep across src/, tests/ and CMakeLists.txt found zero NDEBUG uses, so there is nothing for it to gate. The entire preprocessor-visible delta is -O2→-O3 plus dropping -g, neither of which the extractor reads.
• A -O3-only warning breaking the build. No -Werror anywhere in CMakeLists.txt (only -Wall -Wextra -Wpedantic), so the different -O3 warning set can't fail the Build step.
• Build-type-conditional CMake logic silently dropping targets (which would make "the set of built targets is unchanged" false). Every config generator expression in the tree is $<CONFIG:Debug> (CMakeLists.txt:3279-3280, and the AETHERSDR_SANITIZER block is inert here since the workflow sets no sanitizer). Nothing keys on RelWithDebInfo or Release, so target existence is identical.
• ExternalProject children (vendored Opus) picking up a different build type and changing alerts. Moot for this workflow: codeql-config.yml ignores build/** and third_party/**, so nothing extracted from those trees is reported either way.
• The "~83 GB free" figure, which I can't verify from here. The monotonicity argument carries without it: the identical workflow fit the runner at RelWithDebInfo until 10-02, Release removes -g and adds nothing, so the tree can only shrink. "It can't get worse on disk" survives even if the absolute number is wrong.
• Could not check: whether the next analyze (cpp) run actually goes green, and whether 19 GB leaves durable headroom. 17 of those 19 GB are test executables at ~29 MB each, so headroom erodes as tests are added.

Recommendation

Approve with nits. This is the minimal change that addresses the named cause, the one claim worth attacking ("nothing it analyzes changes") holds under the NDEBUG/config-expression checks above, and the body is honest about what wasn't exercised. Suggested next step: fix the two figures in the committed comment, then merge and watch the first analyze (cpp) run on main.

One framing note for the maintainer, not a change to make here: codeql-config.yml ignores tests/**, yet 17 of the 19 GB — and most of the 39-min build that this file's own header calls "the longest pole" — comes from compiling ~600 test executables whose results are then discarded. Release is a correct symptom fix; a production-targets-only cmake --build build --target … would be the root fix for both disk and wall-clock. It needs its own issue, because it carries a real coverage caveat: any src/ translation unit that reaches the compiler only through a test target's source list would silently drop out of extraction, and that wants checking before anyone narrows the build.

---

_{🤖 aethersdr-agent · cost: $3.0046 · model: claude-opus-5}

[ten9876]

PR #6135 — CodeQL Release build (@ten9876)

Issue fit: #6130 reports C++ CodeQL builds exhausting the hosted runner's disk before results upload. Changing the build type from RelWithDebInfo to Release directly addresses the debug-information footprint while retaining the default target graph. The implementation fits the issue; successful CodeQL extraction and upload remain unverified until the first applicable main run. Reviewed head a7b0285f131d5458fc511c60b8a0f542e89829ce.

Scope

File/group	Change	Claimed?	Verdict
.github/workflows/codeql.yml:107–112	Release configure and rationale comment	Yes	In scope for #6130

Everything in the diff is explained by the issue. The single commit's authored date and subject match this fix. No product behavior, workflow permissions, target selection, dependencies, or release defaults change. GOVERNANCE.md explicitly exempts “Build / CI fixes” from RFC requirements. No unrelated hunks or CHANGELOG entry.

Blockers

None found.

Nits (non-blocking)

1. Correct the disk explanation — .github/workflows/codeql.yml:108–110. “Every test” linking aethercore is inaccurate: my configured head has 609 executable link edges, of which 254 reference libaethercore.a. Also, the body's 317 MB → 29 MB figures do not substantiate the comment's “~4x.” Neither weakens the fix, but preserve the narrower, verifiable explanation:

      # Release omits the debug information carried by RelWithDebInfo.
      # Tests that statically link aethercore duplicate that information;
      # building the default graph with -g exhausted the runner's disk (#6130).

2. Keep the validation boundary explicit — .github/workflows/codeql.yml:112–118. The body correctly says CodeQL itself was not exercised. I likewise did not reproduce its 19 GB full-build measurement or run the extractor/upload. The same compile inputs do not by themselves prove identical analysis results or sufficient disk headroom after the CodeQL database is included. Confirm Build, Perform CodeQL Analysis, and results upload on the next main run before treating #6130 as operationally resolved. This is an outstanding verification item, not a demand for a synthetic CTest.

What I tried to break

• Verify the reported cause: downloaded the cited failed job 111284710455 from run 37151002986. It configured RelWithDebInfo and failed with ClientChainApplet.cpp.o: No space left on device at 2026-10-03T21:44:10Z; this is observed runner evidence, not inferred from the issue.
• Try to lose targets or source coverage: configured the actual PR head twice in isolated directories with the old and new build types using GCC 16.2.1 / Qt 6.12.0. Both configured successfully, with 3,757 compile edges, 2,297 distinct compile inputs, 609 executable link edges, and 612 default all dependencies. After normalizing configuration names and build-directory paths, the entire compile-input graph and default dependency list match. Since the only functional diff is the workflow build type, these two configurations exercise the before/after change directly.
• Try to change preprocessor behavior or accidentally keep debug flags: aethercore's generated flags change from -O2 -g -DNDEBUG to -O3 -DNDEBUG; its definitions match. Audited first-party CMake configuration conditions and found no Release-only target-selection branch. The optimization change means “nothing it analyzes changes” should be read as retained source coverage, not a proven byte-identical database.
• Check review and execution limits: no added or modified test sources or socket tests. This is a headless CI change, so no GUI/bridge session was applicable. No full application build, broad test suite, or CodeQL run was performed. The separate automated code-review skill was unavailable; I independently checked the existing bot review. I do not adopt its unsupported suggestion that issue #6130's ASan precedent is nonexistent: #6136 addresses that separate failure.

CI freshness: the four required PR checks passed, but the earliest run on this head was created 2026-10-03T22:27:12Z (CI/Static Checks: 22:27:14Z), before current main 3e4b14e2 at 2026-10-04T01:13:20Z. Those pull-request checks describe an older merge result, not current main. The C++ CodeQL workflow has push-to-main and scheduled triggers, so the green JS/Python checks are not C++ validation. With non-strict branch protection, a rerun is not automatically forced.

Recommendation

Approve with nits, subject to the normal current-main merge checks. The generated build graph preserves the intended inputs and removes -g; the cited failure is independently confirmed. Correct the explanatory comment and monitor the first C++ CodeQL build/extraction/upload after merge. This is a comment review, not approval; the authenticated account is the PR author.

[ten9876]

Review-body items, current head d38a7d389:

• The ~4x / every-test figures (both reviews): fixed in 23e85e4. See the resolved thread.
• No workflow_dispatch (bot): added in d38a7d3, maintainer call to fold it in. The concurrency comment now covers a branch-dispatched run. actionlint is clean. The trigger has already been used: run 37172958567 is running this head's Release build and CodeQL analysis on the branch. That run is the pre-merge proof that the build fits the runner, which the body previously said only a post-merge main run could show.
• Targets-only build (bot framing note): filed as ci(codeql): build only what CodeQL reports on, after a coverage check #6143, with the coverage check it needs first.
• "The precedent in CodeQL analyze (cpp) fails on every main push: runner out of disk during Build #6130 doesn't exist" (bot): the ASan lane's disk exhaustion is real, and ci(sanitizers): link the ASan lane against a shared core so it fits on disk. Principle VIII. #6136 fixes it with a shared core. The other review already noted this. No change here.
• Validation boundary (second review, nit 2): unchanged and accurate. The dispatch run above covers Build → Analyze → upload on the branch, and the first push-to-main run re-checks it after merge.