Skip to content

The CI work on dev has never reached master, and that merge is the only chance to test the Pages publish path #678

Description

@fdesbiens

master is 95 commits behind dev and carries none of the CI work merged over the past week. That is deliberate — a dev -> master merge is a release event for this project, and cherry-picking was rejected because master has none of the surrounding commits the fixes depend on. #659's serial-loop fix, for instance, would be inert on master, because CTEST_PARALLEL_LEVEL=1 only arrives with #643.

This issue is to track that merge and, more importantly, what has to be watched on it.

Why this merge is the only chance to test part of the CI

deploy_code_coverage runs only on a push to master, and for a push event GitHub takes the workflow files from the pushed commit's own tree. So no pull request, and no push to dev, can ever execute it. The release merge is therefore the first and only execution of:

Everything else in both pull requests has been exercised on dev. These four have not. They rest on reading the actions' contracts at their pinned SHAs plus one throwaway fork probe that fabricated artifacts of the right shape. That is good evidence, but it is not a run.

Two items a release reviewer should look at on their own terms

  • Fixed the AArch64 samples, none of which had ever linked with GCC #673 changes 27 generated port trees plus one ports_arch/ source. It is the only item in this batch that alters shipped port files rather than CI. It is a link-line fix to build_threadx_sample.sh, adding crti.o/crtn.o so that _init/_fini resolve; no kernel or port source changes.
  • Assembled the module ports, which no check had ever compiled #672 renames 29 assembly files from .s to .S under gnu trees, and changes four of them. On a case-insensitive checkout — Windows, and macOS by default — git can need care with a rename that differs only in case. This is worth a line in the release announcement rather than a surprise for downstream users.

What to check on the master push run

  • gcc_check triggers on [ master, dev ], so the merge is also its first master push run. It has been exercised on dev pull requests, so this is not the untested class the Pages actions are, but it has not run in this shape.
  • The published coverage site should carry two directories, one per suite, and not one overwriting the other — the per-configuration reports are nested for exactly this reason.
  • The coverage artifact should contain ThreadX/ and merged.xml and no per_configuration/.

What has to land first

Nothing blocks it technically. #674 is green and ready, and #639 is open; both are candidates to include or to defer deliberately rather than by accident.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions