threadx.git/.github/workflows, branch dev

Added a QEMU module execution harness for the Cortex-M3 and M4 ports (#821)

2026-10-23T17:06:05Z

No Cortex-M module port ran in CI. gcc_check compiles each port's module manager sources and links nothing that loads a module, and the host tests under test/tx/module_manager compile a few portable sources against stubs. A module's start-up, its kernel calls through the supervisor call, the MPU programming on context switches and the fault path that terminates a misbehaving module were exercised only on the Cortex-R52 FVP. test/tx/cmake/module_qemu is a stand-alone CMake project, like test/tx/cmake/riscv, that builds the kernel and Module Manager with a module port's headers, builds test modules position-independent with the port's module linker script, embeds their raw images in manager images, and registers each image with CTest. A Python runner starts it on QEMU's MPS2 board for the core, mps2-an385 for cortex_m3 and mps2-an386 for cortex_m4 built for its FPU with the hard-float ABI, and judges the result line the image prints over semihosting and the exit status it sets. Three images per port: a protected module loaded, started, exercising queues, semaphores, a worker thread and the timer, stopped and unloaded twice with its memory returned; the same module faulting on a read of kernel memory, reported to the fault notification with its module, thread and address and terminated, then stopped and unloaded; and the module built privileged and unprotected, whose identical read succeeds. The fault image is also the check that QEMU's MPU enforces at all. The new module_qemu workflow runs both ports on changes to common/, common_modules/, the two module ports and the harness, installing QEMU from the Ubuntu archive through the bounded apt helpers in scripts/tx_ci_common.sh. Both ports pass 3/3 on QEMU 8.2.2 with Arm GNU 14.3.rel1, using the workflow's commands, with zero compiler warnings; configure, build and run take 9 seconds for both. The AI disclosure check passes. The workflow itself has not run on GitHub yet. Assisted-by: Claude Code (Opus 5.5)

Added the R52 module and S32Z280 examples to the FVP workflow (#804)

2026-10-13T16:06:42Z

The FVP module manager example and the S32Z280 kernel and module examples are each behind a CMake option that defaults to OFF, and no CI lane turned any of them on. The module isolation tests were therefore never linked, and nothing built the S32Z280 images. Both r52_fvp configurations now enable all four example options. The FVP module images join the CTest suite whenever the model is available; the S32Z280 images are built and never run, since CTest registers only FVP images. The header no longer describes these examples as pending. On the Armv8-R AEM FVP 11.32 with GCC 14.3, the default configuration builds 14 images and passes 8/8, and the feature configuration builds 20 and passes 11/11, with zero warnings. CI still builds without executing until FVP_AEMV8R_URL is set. Assisted-by: Claude Code (Opus 5.5)

Enabled FVP execution in the Cortex-R52 workflow (#806)

2026-10-13T15:14:35Z

Fixes #805 r52_fvp only ran the FVP when a repository variable pointed it at the model, and none was set, so every run built the images and executed nothing. The workflow also expected an unpacked model, but Arm ships the FVP as an installer script. The workflow now downloads the 11.32_19 archive from Arm's public permalink, checks it against a pinned SHA-256, and runs Arm's installer with its EULA accepted. The cache is keyed on the checksum. A missing model now fails the job instead of skipping execution. CONTRIBUTING.md no longer describes the repository variable. The workflow's install, locate, and build-and-run steps, run locally as written, download and verify the archive, install 11.32+19, and pass 6/6 default and 9/9 feature on the FVP. The installed binary is identical to the one used for local validation of the port. Assisted-by: Claude Code (Opus 5.5)

Updated artifact and Pages actions to current patch releases

2026-10-13T12:50:05Z

The artifact and Pages workflows pin actions behind their current patch releases. Updated upload-artifact to v7.0.2, download-artifact to v8.0.2 and deploy-pages to v5.0.1, retaining immutable SHA pins. Component sources are unchanged. The ThreadX, SMP, FreeRTOS and RISC-V regression jobs and repository checks passed. Pages deployment was not exercised by the pull request. Assisted-by: Copilot (gpt-6.1-sol) <223556219+Copilot@users.noreply.github.com>

Stopped the coverage deploy running after a cancelled test job

2026-10-06T07:34:50Z

deploy_code_coverage gated on !failure() && !cancelled(). Both report the status of the workflow, not of the job named in needs, so a run_tests that is cancelled leaves both false and the deploy proceeds. On the GUIX run of 5 October 2026 run_tests was never assigned a runner, sat fifteen minutes and was cancelled; the deploy ran anyway and failed with "No artifacts named github-pages were found for this workflow run". A run that executed no test at all reported itself red for a missing artifact. Gated on needs.run_tests.result == 'success' instead, so the deploy runs only when the job that uploads the artifact actually succeeded. A caller passing skip_test gains the same protection: run_tests is skipped, and the deploy no longer attempts a download that cannot succeed. yaml.safe_load parses the file. Against the four run_tests outcomes seen on that GUIX run, the new condition deploys on success and skips on failure, cancelled and skipped; the old one deployed on three of the four. This repository's own suites call the template by relative path and are green on tx, smp, riscv and freertos -- but not the changed line itself: deploy_code_coverage is push-only, so a pull request skips it before the new condition decides anything. Components referencing the template at @master are unaffected until this reaches master. Assisted-by: Claude Code (Opus 5)

Made the build step timeout a template input (#791)

2026-09-30T16:42:59Z

The build step is capped at fifteen minutes for every consumer, on the same shape of assumption the install step carried: that a consumer builds once. Measured build steps are 0.5 minutes for LevelX, 1.1 for FileX and 6.4 for USBX, so fifteen is right for them. GUIX builds five configurations in that step, because its suite is staged across the three steps, and reaches 11.8 minutes. That is 79 per cent of the cap, and it grows with every regression test added -- six advisories landed tests this week. The cap is now an input defaulting to fifteen, matching install_timeout_minutes above. No consumer changes unless it asks to. Assisted-by: Claude Code (Opus 5)

Made the install step timeout a template input (#790)

2026-09-30T16:00:52Z

The install step is capped at ten minutes for every consumer. That suits a consumer that only installs packages, which is all of them bar one: measured install steps run 0.2 to 0.5 minutes, and NetX Duo's secure interoperability job, which builds OpenSSL and wolfSSL from source, takes 2.1 to 2.8. GUIX does not fit. Its regression suite is staged across the install, build and test steps to keep each inside its limit, so the install step also builds a configuration, and on a slow mirror the packages and the ThreadX checkout leave too little of the ten minutes for it. Three runs on dev were lost that way. The cap is now an input defaulting to ten, so a consumer that needs longer asks for it and every other consumer keeps the timeout it has today. Assisted-by: Claude Code (Opus 5)

Normalized the AI disclosure comment and added a check that keeps it so (#762)

2026-09-28T18:03:53Z

* Normalized the AI disclosure line across every tracked file type The repository-wide pass covered source files only, so build files, CMake toolchain files, shell scripts and the GDB and manifest files kept the older per-edit form of the disclosure comment, which names a product and a model version. The Cortex-R52 module manager port then merged after that pass and brought the old form back into the sources as well. Replaced it with the fixed text in all of them, using the comment character each file already uses. Comment-only. 143 files, one line each. The repository now holds 601 files carrying exactly one disclosure line, none carrying the old form, and none carrying more than one. Assisted-by: Claude Code (Opus 5) * Added a check that keeps the AI disclosure comment in its one accepted form Nothing enforced the disclosure convention, so the drift it exists to prevent returned twice: once when a port merged after the normalisation pass carrying the older per-edit form, and once because that pass had covered source files only, leaving build files and scripts untouched for months. Added scripts/check_ai_disclosure.sh, which rejects the superseded per-edit form, a doubled comment marker, more than one disclosure line in a file, and any spelling of the line that is not exact. It runs from repo_checks.yml, a workflow with no path filter, because a source-path filter is what hid the build files the first time. The check passes on this branch. Each of its four rules was confirmed to fail on a tree with that defect reintroduced, and to pass once it was removed. Assisted-by: Claude Code (Opus 5) * Normalised the disclosure lines that landed after this branch Thirteen files reached dev after this branch was written, each carrying the superseded per-edit form. txm_module_manager_dispatch.h reached it with six stacked copies, naming the same product and the same model every time -- the accumulation the fixed text exists to prevent. Each of those files now carries one disclosure line in the accepted form. Where the accepted line was already present, the superseded ones are deleted rather than converted, so no file gains a second. check_ai_disclosure.sh reported eighteen hits across thirteen files before the pass and passes after it. Assisted-by: Claude Code (Opus 5) * Exempted Markdown from the near-miss disclosure check The near-miss rule flags any line carrying the phrase "AI assistance" that is not the accepted text, which is right for source but wrong for documentation. The contribution guide has to quote the accepted line and say when it applies, so the check reports two paragraphs of prose as drift and fails the build. Markdown is now exempt from that rule alone. The three rules that matter for a documentation file -- superseded form, doubled comment marker, duplicate line -- still scan it, so a stale disclosure in a Markdown file is still caught. The check passes against a tree carrying the rewritten contribution guide, and still fails when a near miss is planted in a source file. Assisted-by: Claude Code (Opus 5) * Corrected the trailer command named in the disclosure check The header comment points a reader at git's own trailer parser to find out which agents have touched a file. That parser reads trailers only from a block at the very end of a message, so a squash merge -- which concatenates a branch's messages -- buries every trailer but the last one mid-message, and an indented trailer is skipped outright. On dev it finds 122 attributions where 163 exist. The comment now names count_assisted_by.sh, which reads whole bodies. Assisted-by: Claude Code (Opus 5)

Refreshed the reason gcc_check leaves RISC-V out (#722)

2026-09-10T13:31:58Z

The header explained the exclusion by saying RISC-V "is not regressing" and that adding it would widen the toolchain download. The second half is still true; the first read as though nothing in CI exercised the family at all, which stopped being the case with #717. RISC-V is now the best-covered of the four excluded families rather than the least: regression_test.yml builds both ports and runs 955 tests on them under QEMU -- 475 on RV32 and 480 on RV64, across five build configurations each -- which is more than a compile-and-link check could establish. That is a stronger argument for leaving it out of this workflow than the original, so the sentence now makes it. The download figure is kept and quantified: the two bare-metal toolchains this workflow would have to fetch are about 500 MB apiece. Comment only; no behaviour change. scripts/check_gcc.sh names the same four families but states the exclusion without giving a reason for it, so it needs no matching edit. Assisted-by: Claude Code (Opus 5)

Enabled the RISC-V regression suite in CI for QEMU targets (#717)

2026-09-10T13:08:11Z

* Enable the RISC-V regression suite in CI The riscv: job in regression_test.yml has been present but commented out since the RISC-V CI infrastructure landed (scripts/install_riscv.sh, scripts/build_tx_riscv.sh, scripts/test_tx_riscv.sh, and the CMake tree under test/tx/cmake/riscv/). It has been gated on a note that read 're-enable when RISC-V CI is ready', with no other blocker recorded. The suite is ready. A local run of scripts/build_tx_riscv.sh followed by scripts/test_tx_riscv.sh against upstream/dev builds every RISC-V target and passes every registered test across all ten build configurations: RV32 (five configs): 5 * 95 = 475 tests, 0 failures, 0 timeouts. RV64 (five configs): 5 * 96 = 480 tests, 0 failures, 0 timeouts. The extra RV64 test is threadx_riscv_new_thread_fpu_state_test, which lives beside test/tx/cmake/riscv/regression/CMakeLists.txt and is added only when THREADX_ARCH is risc-v64 -- the RV32 stack builder still leaves the mstatus slot of the frame unwritten. Every test runs on qemu-system-riscv32 / qemu-system-riscv64 with -machine virt, and each configuration completes in roughly thirteen to fifteen seconds. The job is wired the same way the ThreadX, SMP and FreeRTOS suites are: it calls .github/workflows/regression_template.yml with the RISC-V install/build/test scripts and the RISC-V cmake_path, sets result_affix: RISC-V so its check name and artifacts are named, and carries skip_deploy: true because coverage publishing stays on the Linux suites for now. skip_coverage: true is kept because the CMake configurations under test/tx/cmake/riscv match the Linux suite's minus the coverage instrumentation, so gcovr has nothing to read -- the same reason the FreeRTOS lane sets it. The regression_test.yml triggers were not touched, so the RISC-V suite now runs on push and pull_request to master and dev alongside the other three suites. * Said why the RISC-V suite collects no coverage, instead of implying a missing build configuration The comment added with the job read "No coverage build configuration for the RISC-V suite yet". Both halves of what followed are true -- the configurations under test/tx/cmake/riscv are the Linux suite's minus the coverage one, and gcovr has nothing to read -- but "yet" points the next reader at a fix that would not work. Coverage here is not one missing default_build_coverage entry. These tests are bare-metal images run under QEMU with -bios none, and test/tx/cmake/riscv/bsp/syscalls.c has _write to the UART, _exit through the sifive_test device, and stubs for _close, _fstat, _isatty, _lseek, _read and _sbrk -- but no _open. gcov emits a .gcda by opening a path, so instrumenting these builds produces nothing regardless of how they are configured. Nor is the template's TX_COVERAGE=OFF what holds coverage off: test/tx/cmake/riscv is its own top-level project and never declares that option, so the value is inert there. Getting a figure out of this suite needs a transport off the target -- gcov's dump routines over the UART the BSP already drives, or semihosting. Worth stating plainly in a project that asks for 100% coverage, rather than leaving a reader to discover it after adding a configuration that cannot help. Comment only; the job's inputs are unchanged. Assisted-by: Claude Code (Opus 5) --------- Co-authored-by: Frédéric Desbiens