Three open pull requests target dev and run no regression suite at all. Two of them are port changes and one is a new port.
| PR |
what it changes |
checks it actually runs |
| #576 |
ESP32-C6 RISC-V port bring-up |
clang_check, ports_arch_check — no suites |
| #552 |
removes RV32 qemu test scripts |
clang_check, ports_arch_check — no suites |
| #549 |
RV64 lazy FPU stacking |
clang_check, ports_arch_check — no suites |
Why
#652 turned the regression suites on for pull requests to dev. For a pull_request event GitHub decides which workflows run from the head branch's copy of the workflow files, reached through the merge ref — so a branch created before #652 still carries the old regression_test.yml and still gets the old checks.
Only a rebase fixes it. Closing and reopening does not — that fires the reopened event and re-runs whatever the branch already triggered. This was measured on #653 at the time: close/reopen re-ran the four Cortex-M builds and still no regression suites. Both #653 and #639 needed a rebase.
The same now applies to gcc_check, which landed in #675 on 28 Aug: any branch that predates it cannot run the GCC port check either. #674 was rebased for exactly this reason and gcc_check / gnu appeared on it immediately.
Do not confuse this with the other reason a fork PR's checks look empty
A fork pull request's workflow runs are held for maintainer approval and show as action_required, which produces an almost identical symptom — a checks list with nothing on it but eclipsefdn/eca. That is what was actually wrong with #674, and it recurs on every push.
The two are distinguishable, and it is worth doing before writing to anybody:
gh api "repos/eclipse-threadx/threadx/actions/runs?head_sha=<sha>" \
--jq '.workflow_runs[] | "\(.name)\t\(.status)/\(.conclusion)"'
- Runs present but
action_required → nobody approved them. Approve with
gh api -X POST "repos/eclipse-threadx/threadx/actions/runs/<id>/approve".
- Runs completed and successful, with
regression_test absent entirely → this issue. Rebase.
Checked 28 Aug 2026: #576, #552 and #549 are all the second kind.
What to do
Ask the three authors to rebase onto current dev, explaining that it is not about their code — their branches predate the gate, and merging them as-is would put port changes into dev through a suite that has never run on them.
Three open pull requests target
devand run no regression suite at all. Two of them are port changes and one is a new port.clang_check,ports_arch_check— no suitesclang_check,ports_arch_check— no suitesclang_check,ports_arch_check— no suitesWhy
#652 turned the regression suites on for pull requests to
dev. For apull_requestevent GitHub decides which workflows run from the head branch's copy of the workflow files, reached through the merge ref — so a branch created before #652 still carries the oldregression_test.ymland still gets the old checks.Only a rebase fixes it. Closing and reopening does not — that fires the
reopenedevent and re-runs whatever the branch already triggered. This was measured on #653 at the time: close/reopen re-ran the four Cortex-M builds and still no regression suites. Both #653 and #639 needed a rebase.The same now applies to
gcc_check, which landed in #675 on 28 Aug: any branch that predates it cannot run the GCC port check either. #674 was rebased for exactly this reason andgcc_check / gnuappeared on it immediately.Do not confuse this with the other reason a fork PR's checks look empty
A fork pull request's workflow runs are held for maintainer approval and show as
action_required, which produces an almost identical symptom — a checks list with nothing on it buteclipsefdn/eca. That is what was actually wrong with #674, and it recurs on every push.The two are distinguishable, and it is worth doing before writing to anybody:
action_required→ nobody approved them. Approve withgh api -X POST "repos/eclipse-threadx/threadx/actions/runs/<id>/approve".regression_testabsent entirely → this issue. Rebase.Checked 28 Aug 2026: #576, #552 and #549 are all the second kind.
What to do
Ask the three authors to rebase onto current
dev, explaining that it is not about their code — their branches predate the gate, and merging them as-is would put port changes intodevthrough a suite that has never run on them.