Pinned the certification build environment and enabled CI on the certification branch

2026-09-14T22:06:27Z

The regression workflows ran on ubuntu-latest with nothing pinned, and the coverage numbers they produce are certification evidence. Two things follow from that, and the first is urgent rather than theoretical. These sources declare cmake_minimum_required(VERSION 3.0.0) and CMake removed compatibility below 3.5 in 4.0, so this branch stops configuring the day the hosted image moves to CMake 4.x -- no change here, no warning. Worse, the branch did not need GitHub's help to get there: scripts/install.sh ran pip install --upgrade cmake which installs exactly the CMake version that cannot configure these sources. It also installed gcovr 4.1, which is far too old for the tracefile and threshold options the coverage scripts use, and called sudo, which does not exist in a container. The job now runs inside debian:trixie, which carries GCC 14, gcc-multilib and CMake 3.31.6. Being below 4.x, that configures the sources with no policy override and no edit to CMakeLists.txt. The coverage build is 32-bit, so multilib is not optional. install.sh installs the distribution toolchain plus gcovr 8.6, prints all three versions into the job log, and then asserts them: GCC major 14, CMake major below 4, gcovr exactly 8.6. The image tag is a moving target that point releases rebuild, and a toolchain that drifts should fail by name and number rather than quietly produce evidence built with something else. git is installed before the checkout, because actions/checkout otherwise falls back to a REST API tarball and leaves no .git behind, and the commit the evidence was built from is part of the evidence. The Pages preparation step no longer calls sudo, since the steps run as root in the container. Nothing gated on the coverage number before: it was published, not enforced. coverage.sh --merge now ends with a gcovr pass carrying --fail-under-line and --fail-under-branch, after the reports are written so a failed gate still leaves the report that explains it. ThreadX 99.50% line 80.00% branch SMP 99.40% line 83.00% branch These are a ratchet, raised as each batch of gaps closes, and deliberately not 100%: a gate nothing can pass gets switched off. They sit below the measured figures rather than at them, because the same tree does not measure identically twice -- branches on the resume-from-ISR path are reached or missed depending on how the host schedules the run, and two clean runs of the ThreadX suite differ by 2 lines and 19 branches. A gate set at the best observation fails on a tree nobody changed. Verified by raising each threshold above the measurement: line returns 2, branch returns 4, the merged report is still written, and run.sh reports the failure rather than swallowing it -- a run with all 95 tests passing exits 2 when the line gate is not met. regression_test.yml now triggers on the certification branch as well as master. regression_template.yml needed no filter; it is workflow_call only. Publishing stays on master. The deploy job replaces the project's public coverage site wholesale and its condition fires on any push, so without a guard the first push of this branch would have published its numbers as the project's. The certification branch produces its evidence as workflow artifacts instead. Assisted-by: Claude Code (Opus 5)

Upgrade CMake to the latest.

2023-11-10T07:50:36Z

Update CFS usage (#252)

2023-04-20T09:20:15Z

Add Azure DevOps pipelines for ThreadX test

2023-04-12T09:40:17Z

threadx.git/scripts/install.sh, branch v6.4.1_cert

Pinned the certification build environment and enabled CI on the certification branch

Upgrade CMake to the latest.

Update CFS usage (#252)

Add Azure DevOps pipelines for ThreadX test