ci: make C tests and ARM cross-build fail closed - #41
AbdulRehman77777 wants to merge 2 commits into
Conversation
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Approving. This is a better fix than it looks, and it corrects something I got
wrong yesterday.
The option name was doing nothing
CMakeLists.txt:16 defines:
option(EAI_BUILD_TESTS "Build unit tests" OFF)There is no BUILD_TESTS. So the old workflow's -DBUILD_TESTS=ON set an
unrelated variable and left tests off. Measured:
-DBUILD_TESTS=ON -> No tests were found!!!
-DEAI_BUILD_TESTS=ON -> 100% tests passed, 0 tests failed out of 24
Twenty-four tests that have never run in CI.
Which means my report on #39 was wrong
When I restored the trigger in #39 I wrote that C/C++ Tests passed and only
Python was broken. That pass was worthless — the job built zero tests, ctest
found nothing, and || true swallowed the result:
ctest with zero tests, `|| true` -> exit=0 job passes
So eAI had a green C/C++ badge over a suite that was never compiled. Restoring
the trigger made the job run; it took this PR to make it mean something. Both
were needed and I only saw half of it.
--no-tests=error is the right instrument
It is ctest's own answer to exactly the trap that made the old job green:
zero tests, --no-tests=error -> exit=8 job fails
24 tests, --no-tests=error -> exit=0 job passes
Worth noting because I hit the same problem in ebuild and solved it by parsing
"No tests were found" out of the output — necessary there, because that command
wraps several runners including ones with no equivalent flag. Where ctest is
invoked directly, --no-tests=error is better: it is upstream's contract rather
than a string match on a message that could be reworded.
The rest
Dropping || true from ctest and 2>/dev/null || true from the ARM build is the
core of "fail closed". The suppressed stderr on the ARM step is the worse of the
two — it hid both the failure and the reason.
The toolchain path is also genuinely wrong on master:
cmake/arm-cortex-m4.cmake does not exist
cmake/toolchains/toolchain-arm-cortex-m4.cmake exists
so that step was failing to configure and being silenced. With the suppression
removed and the path corrected, the ARM cross-build will actually run — and may
well be red first time, like everything else this repository has not been
checking.
Five lines, four independent defects, each verified. Nice work.
|
Thanks Mr. Srikanth. I really appreciate the detailed review and the explanation around the CI behavior. Glad I could help uncover and fix it. |
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Review — eAI#41 "ci: make C tests and ARM cross-build fail closed"
head: ef4d249 author: AbdulRehman77777 ci: none ran
Verdict: The diagnosis is right and the ARM half is still needed. The C half has
landed on master independently, which is most of why this now conflicts — rebase and
this becomes a three-line PR.
Findings
| # | Severity | File:line | Finding | Recommended fix |
|---|---|---|---|---|
| 1 | Medium | .github/workflows/ci.yml:26-31 |
The test-c hunk is already upstream. master (abd678b, merge of #33) has -DEAI_BUILD_TESTS=ON and ctest --output-on-failure --no-tests=error. git merge-tree against current master conflicts on exactly this hunk and nothing else: master wrote cd build && ctest --output-on-failure --no-tests=error, this branch wrote ctest --test-dir build --output-on-failure --no-tests=error. The two are equivalent. |
Rebase, take master's line for test-c, keep only the build-arm hunk. |
| 2 | Medium | (whole PR) | No CI has ever run on this PR. checks.txt is empty. The base branch's ci.yml has pull_request: branches: [main], so a PR against master does not match the trigger — the exact defect #39 fixes. The fail-closed behaviour this PR introduces is therefore unverified by CI, and cannot be verified here until #39 lands. |
Merge #39 first, then push this so it gets a real run. |
| 3 | Low | .github/workflows/ci.yml:67 + :70-77 |
mkdir -p dist && echo "ARM build complete" > dist/build.txt writes an assertion, not evidence. With || true gone and Actions' default bash -e, it is no longer reached after a failed build — that part of the body's reasoning holds. But upload-artifact has no if-no-files-found, which defaults to warn: a configure/build that succeeds while emitting no .elf/.bin still uploads a directory whose only content says the build completed. |
Add if-no-files-found: error to the upload step and drop dist/build.txt; the artifact itself is the evidence. |
| 4 | Low | cmake/toolchain-arm-cortex-m4.cmake |
The repo carries two Cortex-M4 toolchain files. diff shows them byte-identical apart from line endings (cmake/toolchain-arm-cortex-m4.cmake is LF, cmake/toolchains/toolchain-arm-cortex-m4.cmake is CRLF). This PR picks the toolchains/ one, which is the right choice — it sits with the other eight targets and its own usage comment names that path. The stale copy is what will let the two diverge later. |
Delete cmake/toolchain-arm-cortex-m4.cmake in a follow-up. |
On the claims
The Verification section holds up, and the two things it does not claim are the ones
that matter: ARM compilation is marked NOT RUN with the reason (arm-none-eabi-gcc
absent), and the FS_OPS / HAL_CORE / HAL_MEM compile failures on the macOS host are
named rather than hidden. That is the right shape for a fail-closed PR — with || true
gone, if those failures reproduce under gcc-12 on ubuntu-22.04 the test-c job will
fail at the build step and the 24 tests still will not run. That is the intended outcome,
not a regression, but it should not be a surprise on the first green-or-red run.
The toolchain claim checks out: the old workflow named cmake/arm-cortex-m4.cmake, and
no such file exists at any commit on master.
The body's reasoning about shell semantics is correct — GitHub Actions runs run: steps
under bash -e on Linux by default, so a failing cmake aborts the step.
Architecture conformance
Conforms. §21 Tier 3 (eAI, Advanced); CI configuration inside the owning repo, no
dependency edges added, §5.1 untouched. The change moves the repo toward §28's evidence
policy rather than away from it: a job that reports Implemented while compiling zero
tests is the failure mode §28 exists to prevent.
Proposed changes
rebase onto origin/master
- drop the test-c hunk entirely (already upstream, equivalent form)
- keep the build-arm hunk:
-DCMAKE_TOOLCHAIN_FILE=cmake/toolchains/toolchain-arm-cortex-m4.cmake
-DEAI_BUILD_TESTS=OFF
cmake --build build/arm --parallel $(nproc)
- add if-no-files-found: error to the upload-artifact step
- drop mkdir -p dist && echo "ARM build complete" > dist/build.txt
That leaves a diff of about three lines with no conflict.
Not checked
- Nothing was built or run.
arm-none-eabi-gccavailability, whether the ARM
cross-build actually succeeds, and whether the 24 C tests pass undergcc-12are all
unverified here — the same gaps the author declared. reviewDecision: APPROVEDis recorded; I did not look at who approved or on which
head.
Automated architecture review of ef4d2490d20e — scheduled, model claude-opus-5, checked against the EmbeddedOS Master Design v2.0. Advisory only: this reviewer never approves, requests changes, or merges. Reply here to discuss or push back — a wrong finding is a bug worth reporting.
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Review — eAI#41 "ci: make C tests and ARM cross-build fail closed"
head: 671710c2161bf253e00a9fb57a2ff3ea7aabdd15 author: AbdulRehman77777 ci: fail (policy / Linked Issue; no build job has ever run)
Verdict: Follow-up. One new commit since the last review — 671710c "Merge branch
'master' into fix/eai-ci-verification" — which resolves the conflict and nothing else.
The PR is MERGEABLE again, so finding 1 is settled; findings 2 and 3 are untouched, and
the PR is now blocked on a red required check that was not red last time.
Previous findings
| # | Was | Now | Evidence |
|---|---|---|---|
| 1 | Medium — test-c hunk already upstream, conflicts with master |
Addressed (with a nit, new finding 3 below) | 671710c merges origin/master (e34276e) in; git merge-base --is-ancestor origin/master FETCH_HEAD passes, pr.json reports mergeable: MERGEABLE. |
| 2 | Medium — no CI has ever run on this PR | Untouched, still open | checks.txt lists exactly one check. origin/master:.github/workflows/ci.yml:7 is still pull_request: branches: [main], so a PR targeting master still does not trigger the build workflow. #39 has not landed. |
| 3 | Low — upload-artifact has no if-no-files-found, dist/build.txt is an assertion not evidence |
Untouched | diff.patch leaves the upload-artifact step unmodified; git show origin/master:.github/workflows/ci.yml | grep if-no-files-found returns nothing, and mkdir -p dist && echo "ARM build complete" > dist/build.txt is still on line 67 of the resulting file. |
| 4 | Low — duplicate Cortex-M4 toolchain file (follow-up, not this PR's job) | Untouched, correctly out of scope | git ls-tree -r origin/master still shows both cmake/toolchain-arm-cortex-m4.cmake and cmake/toolchains/toolchain-arm-cortex-m4.cmake. |
Findings
| # | Severity | File:line | Finding | Recommended fix |
|---|---|---|---|---|
| 1 | High | (whole PR) | Required check policy / Policy / Linked Issue is failing (checks.txt, run 34739561827) and mergeStateStatus is BLOCKED. .github/workflows/linked-issue.yml runs the org linked-issue-policy reusable workflow on opened/edited/reopened/synchronize. The PR body references #39 and #40 in prose, but neither is an issue nor carries a closing keyword, so the policy has nothing to link. This is the only check that has ever reported on this PR, and it is red. |
Open (or find) an issue for the CI fail-open defect and add Closes #<issue> to the PR body. Editing the body re-triggers the policy job. |
| 2 | Medium | (whole PR) | Carried over from the last review and still unresolved: the fail-closed behaviour this PR introduces has never been executed by CI, because the workflow it edits does not trigger on PRs to master. The change is still unverified by anything except the author's local run. |
Land #39 (trigger fix) first, then push here so test-c and build-arm produce a real red-or-green. Until then treat the PR body's verification table as local-only evidence. |
| 3 | Low | .github/workflows/ci.yml:28-31 |
The merge resolved the test-c conflict by taking this branch's line and discarding master's. The two commands are equivalent (ctest --test-dir build vs cd build && ctest), but the resolution also deletes the two comment lines master added: # No || true: a failing test must fail the job. --no-tests=error / # catches an empty test set, which ctest otherwise reports as success. That comment is the only place in the file that explains why --no-tests=error is present, and this PR is precisely the change that comment documents. Net effect of the test-c hunk is now -2 comment lines, ±0 behaviour. |
Restore the two comment lines above the ctest call, or drop the test-c hunk entirely and keep master's form — either leaves the PR's real content as the build-arm hunk alone. |
| 4 | Low | .github/workflows/ci.yml:67, :70-77 |
Unchanged from the last review. mkdir -p dist && echo "ARM build complete" > dist/build.txt writes a claim rather than evidence, and upload-artifact has no if-no-files-found, which defaults to warn — a configure+build that succeeds while emitting no .elf/.bin uploads an artifact whose only content asserts the build completed. With || true gone the marker is at least unreachable after a hard failure, so this is Low, not the fail-open defect the PR set out to fix. |
Add if-no-files-found: error to the upload step and delete the dist/build.txt line. The ELF/BIN is the evidence. |
New commits, reviewed on their own merits
671710c is a merge commit. Its only content is the ci.yml conflict resolution
described in finding 3; git diff ef4d2490 FETCH_HEAD shows the other 1,235 insertions
are master catching up (ekf.c, test_ekf.c, tests/CMakeLists.txt, governance
files), not authored here. No defect introduced by the merge itself. The build-arm hunk
is byte-identical to the previously reviewed version and is still the correct fix:
cmake/toolchains/toolchain-arm-cortex-m4.cmake exists on master, cmake/arm-cortex-m4.cmake
never has.
Architecture conformance
Conforms, unchanged from the last review. §21 Tier 3 (eAI, Advanced); CI configuration
in the owning repo; no include, link or manifest edge added, so §5.1 is untouched. The
change moves toward §28's evidence policy — a job reporting success while compiling zero
tests is exactly the state §28 exists to prevent.
Blocked / stale status
Blocked, not stale. The author responded to the last review and did the merge. What
now blocks it is: (a) the red Linked Issue policy check, fixable in the PR body; (b) the
absence of any real CI run, fixable only by landing #39. Neither is in this author's
control beyond (a).
Proposed changes
1. Add "Closes #<issue>" to the PR body -> clears the red policy check
2. Restore the two-line comment above the ctest call in test-c
(or drop the test-c hunk and keep master's form)
3. In the upload-artifact step add: if-no-files-found: error
and delete: mkdir -p dist && echo "ARM build complete" > dist/build.txt
4. Land #39, then push an empty commit here to get the first real CI run
Not checked
- Nothing was built, configured or executed for this review.
arm-none-eabi-gcc
availability, whether the ARM cross-build succeeds, and whether the 24 C tests pass
undergcc-12onubuntu-22.04are all still unverified — the same gaps the author
declared, plus the fact that CI cannot close them until #39 lands. - I did not read the
linked-issue-policy.ymlreusable workflow at
embeddedos-org/.github@92cb596; the cause of the policy failure is inferred from the
PR body containing no closing keyword, not confirmed from the job log. - I did not check whether #39 or #40 are still open or have been superseded.
Automated architecture review of 671710c2161b — scheduled, model claude-opus-5, checked against the EmbeddedOS Master Design v2.0. Advisory only: this reviewer never approves, requests changes, or merges. Reply here to discuss or push back — a wrong finding is a bug worth reporting.
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Thanks @AbdulRehman77777 — the instinct is exactly right, and the individual edits are correct: BUILD_TESTS was never a real option (so test-c was configuring zero tests), cmake/arm-cortex-m4.cmake doesn't exist, and --no-tests=error is the right guard against an empty ctest run. I confirmed the host side locally: -DEAI_BUILD_TESTS=ON builds and 24/24 tests pass.
Three things need to change before this does what the title says, though:
.github/workflows/ci.yml:64-67— the ARM build doesn't compile. With|| truegone,cmake --build build/armfails atcommon/src/tools_builtin.c:20: fatal error: sys/socket.h(newlib has no BSD sockets). I tried-DEAI_PLATFORM_LINUX=OFF -DEAI_PLATFORM_BAREMETAL=ON -DEAI_BUILD_CLI=OFFtoo; same failure. As-is this makesbuild-arm— andrelease, whichneedsit — permanently red. Please either gate that tool behind a platform option that's off forCMAKE_SYSTEM_NAME STREQUAL Generic, or land the source fix first and stack this PR on it.-
.github/workflows/ci.yml:3-8— the workflow never runs here. Triggers aremain/develop, but the repo has onlymaster. Until the triggers includemaster, nothing in this file fails open or closed.
-
.github/workflows/ci.yml:26-31— already on master. #33 landed the sametest-cchange; this branch conflicts with master on that hunk. A rebase should leave only thebuild-armchange.
One caveat from our side: Actions minutes are tight right now, so we're deliberately not gating merges on CI at the moment. That makes point 1 more important, not less — a job that is guaranteed red just burns minutes. Once rebased, could you note what you ran locally (including the ARM build result)? Happy to re-review quickly.
671710c to
06f16a3
Compare
|
Updated based on your review. Rebased onto current |
srpatcha
left a comment
srpatcha
left a comment
There was a problem hiding this comment.
Review — eAI#41 "ci: make C tests and ARM cross-build fail closed"
head: 06f16a3 author: AbdulRehman77777 ci: fail (policy / Policy / Linked Issue; the build workflow has still never run on this PR)
Verdict: Follow-up, third look. Rebased onto master and substantially rewritten:
the test-c hunk is gone and two real commits took its place — 5d8bdd6 gates host
socket code off bare-metal targets, 06f16a3 makes the ARM job fail closed. I built
this one instead of reading it. Every build claim in the PR body reproduces: the ARM
cross-build passes and emits exactly 8 static libraries, the same command on origin/master
fails outright, and the host suite is green at 25/25. Prior findings 3 and 4 are resolved;
1 and 2 are untouched and still block. The new code is sound but carries one High that
defeats the PR's own purpose (build-arm still cannot execute) and two Mediums.
Previous findings
| # | Was | Now | Evidence |
|---|---|---|---|
| 1 | High — required check policy / Policy / Linked Issue red |
Untouched, still open | checks.txt (run 34919014364) still fail; pr.json mergeStateStatus: BLOCKED; the body updated 2026-09-15T01:53:30Z still references #39/#40 in prose with no closing keyword. |
| 2 | Medium — no CI has ever run on this PR | Untouched, still open | .github/workflows/ci.yml:7-8 at this head is still pull_request: branches: [main]. #39 is still open and is itself BLOCKED. See new finding 1 — it does not end when #39 lands. |
| 3 | Low — merge dropped the two comment lines above ctest |
Resolved | Rebase dropped the test-c hunk entirely. git show FETCH_HEAD:.github/workflows/ci.yml lines 29-30 carry master's comment intact. |
| 4 | Low — no if-no-files-found, dist/build.txt asserted rather than evidenced |
Resolved in 06f16a3 |
path: build/arm/**/*.a + if-no-files-found: error; the mkdir -p dist && echo "ARM build complete" line is gone. |
| 5 | Low — duplicate Cortex-M4 toolchain file | Untouched, declared out of scope | Both cmake/toolchain-arm-cortex-m4.cmake and cmake/toolchains/toolchain-arm-cortex-m4.cmake still present at head. Still open as a follow-up; the PR body names it as out of scope, which is a fair call. |
What I verified by running it
arm-none-eabi-gcc is available on the review host, so the central claim is no longer
inferred. Built from git archive FETCH_HEAD in a scratch tree; the repo checkout was
not touched.
| Check | Command | Result |
|---|---|---|
| ARM configure | cmake -B build/arm -G Ninja -DCMAKE_TOOLCHAIN_FILE=cmake/toolchains/toolchain-arm-cortex-m4.cmake -DEAI_BUILD_TESTS=OFF |
PASS |
| ARM build | cmake --build build/arm --parallel 4 |
PASS — 73/73, 8 .a produced, 52 -Wall -Wextra warnings, 0 errors |
ARM build on origin/master (counterfactual) |
same two commands | FAIL — common/src/tools_builtin.c:20: fatal error: sys/socket.h: No such file or directory, 0 artifacts |
| Host build | cmake -B build -DEAI_BUILD_TESTS=ON && cmake --build build --parallel 4 |
PASS — 0 errors |
| Host tests | ctest --test-dir build --output-on-failure --no-tests=error |
PASS — 25/25 |
| Preserved symbols on ARM | arm-none-eabi-nm -g --defined-only |
eai_tool_http_get_register, eai_min_router_infer_cloud, eai_connector_{mqtt,opcua,modbus}_ops all PRESENT |
The counterfactual is the important row. 2>/dev/null || true was not hiding a cosmetic
problem — it was hiding a build that produced nothing at all, and then writing
dist/build.txt saying "ARM build complete". The diagnosis in the PR body is correct and
the fix is real. The "8 static libraries" claim matches artifact-for-artifact.
Findings
| # | Severity | File:line | Finding | Recommended fix |
|---|---|---|---|---|
| 1 | High | .github/workflows/ci.yml:59 |
The ARM job this PR makes fail-closed still cannot execute, and landing #39 will not change that. build-arm declares needs: [test-c, test-python], and test-python is red on master for an unrelated reason. Run 33359431271 — the only run in which this workflow has ever executed, on #39 — reports Python Tests fail and Cross-compile ARM Cortex-M4 skipping. Root cause is a second fail-open || true in the same file this PR set out to de-fail-open: pip install -r requirements.txt 2>/dev/null || true, where no requirements.txt exists at the repo root (git ls-tree -r origin/master finds only bindings/python/pyproject.toml). The swallow hides the missing file, numpy — imported at tests/unit/test_unit_core.py:10 — is never installed, and pytest exits 2 during collection. Verified locally on Python 3.11.16 / pytest 9.1.1, the same versions the failing job used: with numpy present, python -m pytest tests/ -q on origin/master is 29 passed. So the fail-closed build-arm job lands, is never run, and reports nothing. |
pip install pytest pytest-cov numpy, and replace the || true with a guarded install. Fix PR opened — see "Proposed changes". |
| 2 | Medium | CMakeLists.txt:66-68 |
set(EAI_PLATFORM_BAREMETAL ON) is inert, and so is set(EAI_PLATFORM_LINUX OFF) beside it. git grep EAI_PLATFORM_BAREMETAL at this head returns three hits: the option(), this set(), and platform/src/hal/baremetal/core_baremetal.c:8, which tests it as a C preprocessor macro that no target_compile_definitions ever defines. core_baremetal.c is absent from platform/CMakeLists.txt's source list and from every target_sources(), so it is compiled into no configuration at all. platform/CMakeLists.txt:32,40 selects HAL sources with if(WIN32) … elseif(UNIX), and a CMAKE_SYSTEM_NAME=Generic build is neither — so the Cortex-M4 target gets no HAL core, memory, timer, thread, fs or net implementation whatsoever. Verified: arm-none-eabi-ar t build/arm/platform/libeai_platform.a → platform.c.obj platform_linux.c.obj platform_windows.c.obj platform_container.c.obj eai_api_platform.c.obj, 11 defined symbols, eai_hal_baremetal_core_ops absent. The only platform adapter object shipped for Cortex-M4 is the Linux one. The net effect of the line is to make the build look like it selected a bare-metal adapter while nothing changed, and it makes README.md:29 ("Platform adapters: … bare-metal … builds eai_platform") wrong in a way the new green ARM build helps hide. §28 requires code that exists and is usable for Implemented. |
Either drop the two inert set() lines, or wire it up: an else() branch in platform/CMakeLists.txt adding target_sources(eai_platform PRIVATE src/hal/baremetal/core_baremetal.c) and target_compile_definitions(eai_platform PUBLIC EAI_PLATFORM_BAREMETAL). Do not leave a variable set with no consumer. |
| 3 | Medium | framework/src/connector_mqtt.c:11-21, connector_opcua.c:11-21, connector_modbus.c:11-21 |
The body says socket-backed connectors "report EAI_ERR_UNSUPPORTED". That holds for .connect only. The stub eai_connector_ops_t leaves .disconnect, .read, .write and .subscribe NULL, and framework/src/orchestrator.c:81,94 converts a NULL read/write into EAI_ERR_NOT_FOUND — indistinguishable from "no connector by that name", which sends the caller after the wrong bug. Worse, eai_fw_conn_connect_all (framework/src/connector_can.c:234-248) logs the UNSUPPORTED return, returns EAI_OK regardless, and never sets state = EAI_CONN_ERROR — so on a bare-metal image connector bring-up reports success. The swallow predates this PR, but this PR is what makes all three socket connectors return an error there, so it is newly load-bearing: fail-open behaviour inside a fail-closed PR. connector_can.c already solves the same problem the other way — #ifdef __linux__ with all five ops retained and runtime error returns — and that is the pattern to copy. |
Give the stub structs the full op set, each returning EAI_ERR_UNSUPPORTED. Separately (own PR): make eai_fw_conn_connect_all propagate the first failure and set EAI_CONN_ERROR. |
| 4 | Low | .github/workflows/ci.yml:62 |
sudo apt-get install -y gcc-arm-none-eabi cmake ninja-build with no preceding apt-get update. test-c does run apt-get update -qq; build-arm runs on its own runner and does not. On a stale index this 404s, and now that || true is gone it fails the job hard — correct behaviour, wrong reason, and it will read as "the ARM build broke". Pre-existing line, immediately adjacent to the hunk. |
sudo apt-get update -qq && sudo apt-get install -y … |
| 5 | Low | .github/workflows/ci.yml:66-71 |
The artifact is better evidence than dist/build.txt was, but it should not be read as more than it is: the Generic configuration links nothing. cli/CMakeLists.txt holds the only add_executable, and this PR sets EAI_BUILD_CLI OFF for Generic, so the job stops at ar. Verified: the ARM archives carry unresolved references to fopen, fprintf, printf, malloc and time, none of which are ever resolved, and the toolchain's own -Wl,--print-memory-usage (cmake/toolchains/toolchain-arm-cortex-m4.cmake:20) never runs. A green build-arm proves "compiles", not "links" or "fits in flash". Per §28 that is Implemented, not Validated. |
Say so in the PR body so the artifact is not over-read later. Follow-up: a minimal linked smoke target for Generic with a stub linker script would make this job mean what people will assume it means. |
Not repeated here: the points already made in the two earlier reviews and in the author's
own comment thread. The PR body's verification section is honest — it labels ARM
configure/build PASS, the macOS host test build FAIL with the reason, and actionlint
NOT RUN with the reason. That is the right shape, and finding 5 is a request to extend
it, not a correction of it.
Architecture conformance
Conforms. §21 Tier 3 (eAI, Advanced); all of it is intra-repo CI and build
configuration in the owning repository. §5.1 is untouched — no #include, link line,
target_link_libraries entry or manifest edge is added, and the new gating only removes
edges on Generic targets, so nothing points up a tier. §16.1 ("eAI is optional; the
kernel cannot require it") is unaffected, and the change is in the spirit of its
"keep model-format and accelerator adapters modular" rule.
Against §28: a net improvement. Removing 2>/dev/null || true from a build step is
exactly what the evidence policy exists to force, and the counterfactual above proves the
suppression was hiding a total failure. Findings 1 and 5 are where it stops short —
finding 1 because the job still cannot run, finding 5 because a compile-only artifact
does not reach Validated. §22's Hardware Support Tiers are silent on which of those a
cross-compile job has to demonstrate; see the proposal appended for 2026-09.
Proposed changes
On this PR:
1. Give the three connector stubs the full op set returning EAI_ERR_UNSUPPORTED
(finding 3) — mirrors connector_can.c
2. CMakeLists.txt: drop the inert set(EAI_PLATFORM_BAREMETAL ON) /
set(EAI_PLATFORM_LINUX OFF), or wire core_baremetal.c into
platform/CMakeLists.txt with a matching compile definition (finding 2)
3. ci.yml: sudo apt-get update -qq && sudo apt-get install -y ... (finding 4)
4. PR body: state that build-arm compiles but never links (finding 5)
5. PR body: add "Closes #<issue>" to clear the red Linked Issue check
(prior finding 1 — still the thing blocking merge)
Nit, while you are in CMakeLists.txt: the Generic condition is now tested in two
places — CMakeLists.txt:66 and common/CMakeLists.txt:18. One variable set at the
root and read in common/ would keep them from drifting.
Elsewhere (finding 1) — opened as a separate PR against master, since it blocks
this PR's job from ever running and is not this PR's file to fix:
.github/workflows/ci.yml, test-python:
- pip install pytest pytest-cov
- pip install -r requirements.txt 2>/dev/null || true
+ pip install pytest pytest-cov numpy
+ if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
Blocked / stale status
Blocked, not stale. The author responded to the last review and did substantially
more than was asked. Three things block it, in order of who can clear them:
- The red
Linked Issuepolicy check — clearable by the author, today, by editing the
body. This is the only thing standing between the PR and mergeability. - #39 (workflow trigger) must land before this workflow runs on a PR to
masterat all.
#39 is itselfBLOCKED. - Even then,
build-armstays skipped untiltest-pythonis green — finding 1. A fix
PR for that is open; it is not the author's to carry.
Not checked
- CI toolchain differs from mine. I built with
arm-none-eabi-gcc 14.2.1and
gcc 15.2.0; the workflow pinsubuntu-22.04withgcc-12and whatever
gcc-arm-none-eabithat image resolves to (10.3). A newlib header difference between
10.3 and 14.2 could still change the ARM result. My PASS is strong evidence, not proof
for the CI environment. - Nothing was executed on hardware or in an emulator, and nothing was linked — see
finding 5. Whether this code runs on a Cortex-M4 is unknown and untested by anything in
this repository. - The 52
-Wall -Wextrawarnings in the ARM build were not triaged individually; the job
does not use-Werror, so none of them fail it. - I did not read the
linked-issue-policy.ymlreusable workflow at
embeddedos-org/.github. The cause of the red policy check is inferred from the absence
of a closing keyword in the body, consistent across all three reviews, not confirmed
from the job log. - macOS was not available; the
HAL_CORE/HAL_MEM/FS_OPSApple test-portability
gap the author reports is neither confirmed nor refuted here. - I did not assess #42 or the two dependabot PRs beyond confirming they do not touch
test-python.
Automated architecture review of 06f16a35bd4d — scheduled, model claude-opus-5, checked against the EmbeddedOS Master Design v2.0. Advisory only: this reviewer never approves, requests changes, or merges. Reply here to discuss or push back — a wrong finding is a bug worth reporting.
This branch has not been deployed
2 participants
Problem
The ARM CI job used a nonexistent toolchain path, the wrong test option, and
suppressed configure/build failures. Once those errors were allowed to surface,
the Generic Cortex-M4 build failed because host socket implementations were
compiled against bare-metal newlib, which has no
sys/socket.h.Change
CMAKE_SYSTEM_NAME=Genericas bare metal and disable the host CLIEAI_ERR_UNSUPPORTEDfor socket-backed APIs/connectorsEAI_BUILD_TESTS=OFF, with no error suppressionThe native C test change was dropped during rebase because it is already on
master. Workflow trigger changes remain separate in #39. Python CI and theduplicate Cortex-M4 toolchain file are out of scope.
Local verification
eai_common,eai_min,eai_framework):PASS
define
HAL_CORE/HAL_MEM/FS_OPSfor Windows and Linux; this is thepre-existing Apple test portability issue already documented on this PR
git diff --check: PASSSrikanth independently reported 24/24 host tests passing on Linux. Upstream is
currently conserving Actions minutes, and #39 is still open, so local ARM
verification is the build evidence for this update.