From 977e14e776aed933446835c825b18aa4ca521577 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Desbiens?= Date: Mon, 24 Aug 2026 11:30:19 -0400 Subject: [PATCH] Ran the regression suites on dev, where the pull requests actually are (#652) The ThreadX, SMP and FreeRTOS-compatibility suites triggered on master only, for both push and pull_request. dev is the integration branch, so these suites gated no pull request that anybody opened: the last dev run of any kind was a manual workflow_dispatch on 2026-08-18. This is the same defect ports_arch_check.yml already carries a comment about, where it cost eight months of ports drifting from ports_arch unnoticed. ci_cortex_m.yml has it too and is handled separately. That 2026-08-18 run failed, which is the reason to check before switching this on rather than after. Two tests failed: threadx_timer_simple_test in the ThreadX suite, with ERROR #28, and threadx_thread_priority_change in the SMP suite, with a timeout. Both were fixed two days later -- the first by running the suites one test at a time (#643), which is what a timer test failing only under parallel load wants, and the second by #647 by name. Verified before this commit rather than assumed: both suites were re-run on this tree, and all 1030 tests pass across all ten build configurations, the ThreadX suite in 34 to 64 seconds per configuration and the SMP suite in 61 to 63. The 2026-08-18 run took 36m19s, of which a single test that has since been given a budget accounted for 439 seconds. No paths filter is added deliberately. The suites build the linux port, so a filter would have to enumerate what cannot affect them, and the failure mode of getting that list wrong is a regression that merges because the filter excluded the file that caused it. The deploy job needs no guard: regression_template.yml already restricts deploy_code_coverage to push and workflow_dispatch, and restricts the coverage PR comment to pull requests from the repository itself, so neither fires for a pull request from a fork. Assisted-by: Claude Opus 5 --- .github/workflows/regression_test.yml | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/.github/workflows/regression_test.yml b/.github/workflows/regression_test.yml index 8fa97474..329f448c 100644 --- a/.github/workflows/regression_test.yml +++ b/.github/workflows/regression_test.yml @@ -1,13 +1,24 @@ name: regression_test -# Controls when the action will run. Triggers the workflow on push or pull request -# events but only for the master branch +# Runs the ThreadX, SMP and FreeRTOS-compatibility regression suites. +# +# dev is included as well as master, for the same reason ports_arch_check.yml +# names it: dev is the integration branch, so a check that runs only against +# master gates nothing that anybody opens. Until now these suites ran on no +# pull request that anybody actually raised, and the last dev run of any kind +# was a manual workflow_dispatch. +# +# That run, on 2026-08-18, failed two tests: threadx_timer_simple_test in the +# ThreadX suite and threadx_thread_priority_change in the SMP one. Both are +# fixed -- the first by running the suites one test at a time (#643), the +# second by #647 -- and both suites now pass all 1030 tests across all ten +# build configurations. The suites were never the problem; the trigger was. on: workflow_dispatch: push: - branches: [ master ] + branches: [ master, dev ] pull_request: - branches: [ master ] + branches: [ master, dev ] # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: