Only consume artifacts from the real firmware workflow

[Raffi1202]

Problem

No issue filed; observed on upstream CI. When a PR touches only non-code paths, the non-code-change.yaml stub runs instead of ci.yml. Both are named "Build firmware", so the stub's success triggers "PR Test Builds", whose publish job fails at "Download PR number" with Artifact not found for name: pr-number. Upstream examples: run 34502954072 (triggered by stub run 34502620127) and run 34253938364 (stub run 34253603715); six such failures between 2026-09-08 and 2026-09-10. The size-report job on master already skips the stub via the guard step from #11878, but only after starting a runner, checking out and querying the jobs API.

Cause

.github/workflows/ci.yml:1 and .github/workflows/non-code-change.yaml:1 share name: Build firmware. .github/workflows/pr-test-builds.yml:17-19 gates publish only on workflow_run.event == 'pull_request' and conclusion == 'success', both true for the stub, then downloads pr-number unconditionally (lines 31-36). .github/workflows/ci-size-report.yml:138-141 uses the same job-level condition; the added name check does not tell the two files apart.

Change

Adds github.event.workflow_run.path == '.github/workflows/ci.yml' to the job-level if: of publish in pr-test-builds.yml and pr-comment in ci-size-report.yml. Stub runs no longer enter either job. publish-baseline and the existing "Check upload-artifacts job succeeded" step are untouched.

Test

Not run upstream: the "Build firmware" run for this head (34614441492) is awaiting approval, and workflow_run consumers execute the default-branch file anyway. Verified in the fork, where the same guard is on the default branch (Raffi1202#12, merge ac6fbcd):

• Before: stub run 34612708023 triggered CI Size Report 34613019605, pr-comment failed at "Download PR number" (fork master then lacked the Fix size-diff PR comment crashing when non-code-change build stub fires #11878 guard step).
• After: CI Size Report 34614556238 and 34616048856 ran pr-comment through all artifact downloads and the PR comment, so workflow_run.path is populated and matches for real ci.yml runs.
• pr-test-builds.yml does not execute in the fork (gated on github.repository == 'iNavFlight/inav'); its hunk is the identical expression, checked by reading only.

Flash / RAM

Not measured yet. The upstream firmware CI has not been released for this PR, so no size report exists.

Docs

No documentation change needed: no file under docs/ describes the consumer trigger conditions, and .github/workflows/README.md documents the triggers by workflow name, which is unchanged.

[github-actions]

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

• maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

• maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

---

This is an automated suggestion to help route contributions to the appropriate branch.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Restrict artifact consumers to the firmware CI workflow

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Restricts artifact consumers to successful pull-request runs from .github/workflows/ci.yml.
• Prevents same-named placeholder workflows from causing missing-artifact failures.
• Leaves pre-release baseline publishing unchanged.

Diagram

graph TD
  F["Firmware CI"] --> G{"ci.yml PR success?"} -->|Yes| S["Size report"]
  P["Placeholder workflow"] --> G
  G -->|Yes| T["Test builds"]
  G -->|No| K["Jobs skipped"]
  N["Pre-release build"] --> B["Baseline publish"]

Loading

High-Level Assessment

The workflow path guard is the most direct and reliable approach because workflow display names are not unique. It preserves existing workflow_run triggers while preventing artifact consumers from accepting runs that cannot provide the required artifacts.

Files changed (2) +2 / -0

Bug fix (2) +2 / -0

ci-size-report.ymlLimit PR size reports to the real firmware workflow +1/-0

Limit PR size reports to the real firmware workflow

• Adds a workflow_run path condition to the PR comment job so only '.github/workflows/ci.yml' runs can consume size-report artifacts. Baseline publishing from the pre-release workflow remains unchanged.

.github/workflows/ci-size-report.yml

pr-test-builds.ymlLimit test-build publishing to the real firmware workflow +1/-0

Limit test-build publishing to the real firmware workflow

• Requires successful pull-request runs to originate from '.github/workflows/ci.yml' before downloading and publishing firmware artifacts. This excludes successful placeholder runs sharing the 'Build firmware' name.

.github/workflows/pr-test-builds.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Valid firmware builds are skipped 🐞 Bug ≡ Correctness

Description

Both consumer jobs now require github.event.workflow_run.path to equal the firmware workflow path,
but no repository fixture or convention establishes that this property is populated for
workflow_run events. When the property is absent, the condition evaluates false and valid
pull-request builds are skipped, preventing both artifact consumers from publishing their reports or
builds.

Code

.github/workflows/pr-test-builds.yml[19]

+      github.event.workflow_run.path == '.github/workflows/ci.yml' &&

Evidence

The changed guards make both jobs depend on workflow_run.path. The repository's consumers
otherwise identify the run by workflow name, event, and conclusion, while ci.yml is the
pull-request workflow that uploads the artifacts consumed downstream; no repository fixture or
documentation verifies that workflow_run.path is available in this event payload.

.github/workflows/pr-test-builds.yml[8-20]
.github/workflows/ci-size-report.yml[42-45]
.github/workflows/ci-size-report.yml[138-142]
.github/workflows/ci.yml[5-19]
.github/workflows/ci.yml[126-139]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The consumers require `github.event.workflow_run.path`, but the repository does not establish that this property is present in `workflow_run` event payloads. An absent property makes the condition false, so valid pull-request firmware runs do not reach the artifact consumers.

## Fix Focus Areas
- .github/workflows/pr-test-builds.yml[17-20]
- .github/workflows/ci-size-report.yml[138-142]

## Recommended Fix
Replace the path-based guard with a reliably available identifier for the real firmware workflow, such as its workflow ID or another supported discriminator. Preserve the existing pull-request and successful-conclusion checks, and ensure both consumers reject `non-code-change.yaml` without excluding valid `.github/workflows/ci.yml` runs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: 🚀 Fast: This is a small, localized CI condition change with a clear scope and no security, data, or broad logic risk.

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Valid firmware builds are skipped 🐞 Bug ≡ Correctness

Both consumer jobs now require github.event.workflow_run.path to equal the firmware workflow path,
but no repository fixture or convention establishes that this property is populated for
workflow_run events. When the property is absent, the condition evaluates false and valid
pull-request builds are skipped, preventing both artifact consumers from publishing their reports or
builds.

Agent Prompt

## Issue description
The consumers require `github.event.workflow_run.path`, but the repository does not establish that this property is present in `workflow_run` event payloads. An absent property makes the condition false, so valid pull-request firmware runs do not reach the artifact consumers.

## Fix Focus Areas
- .github/workflows/pr-test-builds.yml[17-20]
- .github/workflows/ci-size-report.yml[138-142]

## Recommended Fix
Replace the path-based guard with a reliably available identifier for the real firmware workflow, such as its workflow ID or another supported discriminator. Preserve the existing pull-request and successful-conclusion checks, and ensure both consumers reject `non-code-change.yaml` without excluding valid `.github/workflows/ci.yml` runs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools