mirror of
https://github.com/eclipse-threadx/threadx.git
synced 2026-10-06 06:59:08 +08:00
Enabled the RISC-V regression suite in CI for QEMU targets (#717)
* 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) <noreply@anthropic.com> --------- Co-authored-by: Frédéric Desbiens <frederic.desbiens@eclipse-foundation.org>
This commit is contained in:
co-authored by
Frédéric Desbiens
parent
42f1d2bcf0
commit
18abe103af
@@ -98,24 +98,38 @@ jobs:
|
||||
# No coverage build configuration yet; the suite covers the creation
|
||||
# paths of the layer rather than all of it.
|
||||
skip_coverage: true
|
||||
# riscv: disabled — re-enable when RISC-V CI is ready
|
||||
# riscv:
|
||||
# permissions:
|
||||
# contents: read
|
||||
# issues: read
|
||||
# checks: write
|
||||
# pull-requests: write
|
||||
# pages: write
|
||||
# id-token: write
|
||||
# uses: ./.github/workflows/regression_template.yml
|
||||
# with:
|
||||
# install_script: ./scripts/install_riscv.sh
|
||||
# build_script: ./scripts/build_tx_riscv.sh
|
||||
# test_script: ./scripts/test_tx_riscv.sh
|
||||
# cmake_path: ./test/tx/cmake/riscv
|
||||
# result_affix: RISC-V
|
||||
# skip_deploy: true
|
||||
# skip_coverage: true
|
||||
riscv:
|
||||
permissions:
|
||||
contents: read
|
||||
issues: read
|
||||
checks: write
|
||||
pull-requests: write
|
||||
pages: write
|
||||
id-token: write
|
||||
uses: ./.github/workflows/regression_template.yml
|
||||
with:
|
||||
install_script: ./scripts/install_riscv.sh
|
||||
build_script: ./scripts/build_tx_riscv.sh
|
||||
test_script: ./scripts/test_tx_riscv.sh
|
||||
cmake_path: ./test/tx/cmake/riscv
|
||||
result_affix: RISC-V
|
||||
skip_deploy: true
|
||||
# No coverage from this suite, and not for want of a build configuration.
|
||||
# These tests are bare-metal images run under QEMU with -bios none, and
|
||||
# test/tx/cmake/riscv/bsp/syscalls.c gives them _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 would produce nothing to read.
|
||||
#
|
||||
# test/tx/cmake/riscv/CMakeLists.txt is its own top-level project and does
|
||||
# not declare the TX_COVERAGE option that test/tx/cmake and test/smp/cmake
|
||||
# do, so the OFF the template exports is inert here rather than the thing
|
||||
# holding coverage off.
|
||||
#
|
||||
# Collecting it therefore needs a transport off the target -- gcov's dump
|
||||
# routines over the UART the BSP already drives, or semihosting -- and not
|
||||
# a default_build_coverage entry beside the other five configurations.
|
||||
skip_coverage: true
|
||||
deploy:
|
||||
# Publishing the coverage report stays on master. Adding dev to this
|
||||
# workflow's triggers was meant to run the suites on the branch the pull
|
||||
|
||||
Reference in New Issue
Block a user