[Iva-L]

Related Issue(s)	Supersedes #6204
Has Unit Tests (y/n)	n (CI workflow change)
Documentation Included (y/n)	n
Generative AI was used in this contribution (y/n)	y

---

Change Description

Adds ext-fprime-stm32-baremetal-reference.yml, a thin dispatcher that fires workflow_dispatch on fprime-community/fprime-stm32-baremetal-reference's own hil.yml, polls the remote run, and reports the result back as a hil-tests Check Run on this commit/PR — following the same pattern as #6231 ("ext-ci orchestrator") and the fprime-workshop-led-blinker#167 example.

Single job, hosted ubuntu-22.04:

1. Resolves the F´ SHA (and PR number, for a fprime-gds@pr-<N> upgrade on the remote side) to dispatch — the PR head SHA for pull_request, github.sha otherwise.
2. Fires createWorkflowDispatch on the target repo's hil.yml, passing fprime_repository/fprime_ref/fprime_pr_number/dispatch_id inputs (same names fprime-workshop-led-blinker#167's ci.yml uses), and creates a queued hil-tests Check Run.
3. Correlates the resulting remote run by matching dispatch_id against its run-name, polls it to completion via the GitHub API, and updates the Check Run to the remote run's final conclusion.
4. A finalize step (if: always()) closes the Check Run as cancelled/failure if the dispatcher job itself is cancelled or crashes mid-poll, so nothing is ever left in_progress forever.

Same triggers as the superseded #6204 version: nightly schedule, push: release/**, pull_request: [devel, release/**], and workflow_dispatch. Fork PRs of nasa/fprime are never dispatched (same-repo-head check) — the real trust gate against untrusted F´ refs lives on the receiving side, where the target repo's release/**], and workflow_dispatch. Fork PRs of nasa/fprimeare never dispatched (same-repo-head check) — the real trust gate against untrusted F´ refs lives on the receiving side, where the target repo'shil-hardware` environment requires human approval before a dispatched ref reaches the board.

Requires one new secret, HIL_DISPATCH_TOKEN (a fine-grained PAT scoped to fprime-community/fprime-stm32-baremetal-reference with actions: write and Actions-run read access) — no callback secret is needed on the external repo under this polling design, unlike #6204's HIL_CALLBACK_TOKEN.

Rationale

#6204 put the self-hosted Pi runner and the full build/flash/HIL-test workflow in nasa/fprime, with only a thin /run-hil dispatcher on the reference repo. Per maintainer direction, that's reversed: the runner and hardware-facing workflow should live on fprime-community/fprime-stm32-baremetal-reference (the repo that owns the hardware), and nasa/fprime should only dispatch — the same "external CI" shape the maintainers are rolling out project-wide (see #6231, fprime-workshop-led-blinker#167). This also drops the two-secret commit-status-callback design in favor of the one-token polling + Check Run pattern already prototyped in #6231, eliminating the need for a callback secret.

Testing/Review Recommendations

• Companion PR on fprime-community/fprime-stm32-baremetal-reference adds the receiving hil.yml (the build/flash/HIL-test workflow, moved there from Add fprime-stm32-baremetal-reference CI and HIL test workflows #6204) — dispatch can't be exercised end-to-end until both land and HIL_DISPATCH_TOKEN/the hil-hardware environment exist.
• The dispatch → correlate → poll → report logic has not yet run against real GitHub Actions (blocked on the secret); please review the script logic directly.

Future Work

• Run one real end-to-end test once the secret and environment exist: trigger a dispatch and confirm the full chain (dispatch → remote run → required-reviewer approval → Check Run reported back) works.

Contributor Checklist

• I have the rights to contribute this change set under the Apache-2.0 license.
• I agree to be bound by the contributor guidelines.

AI Usage (see policy)

Generative AI (Claude) was used to: Write the CI workflow file, documentation and help with PR description.

• This contribution follows the F´ AI development skills (entered through AGENTS.md).

[Iva-L]

Closing in favor of JPL-Devin#296, which plugs fprime-community/fprime-stm32-baremetal-reference into the general-purpose ext-ci orchestrator (from #6231) via a manifest entry, rather than a bespoke per-repo dispatcher workflow. Once that lands, nasa/fprime needs no stm32-specific workflow file, secret, or Check Run logic at all — the orchestrator's existing dispatch/poll/report machinery covers it.