Fix publish-baseline never firing due to unrelated Release job failures

[sensei-hacker]

Summary

publish-baseline (in ci-size-report.yml, part of the RAM/flash size-diff
PR comment feature) never actually published a baseline, even on branches
that were pushing and building successfully. PR #11800 (based on
release/9.1) still showed "No size baseline is available yet" despite
CI having run successfully for days.

Root Cause

publish-baseline gated on github.event.workflow_run.conclusion == 'success' for the entire "Build pre-release" (nightly-build.yml) run.
But that workflow also runs a separate Release job that publishes a
nightly build to iNavFlight/inav-nightly using NIGHTLY_TOKEN — a job
completely unrelated to producing the size report. When that job fails
(confirmed live: Bad credentials from an invalid/expired NIGHTLY_TOKEN
on a real release/9.1 push), it drags the entire run's conclusion to
failure, even though every build job — including the one that produces
the size-report/branch-name artifacts publish-baseline needs —
succeeded. As a result, publish-baseline silently never ran, and no
size-baseline-* release has ever existed in iNavFlight/pr-test-builds.

Changes

• .github/workflows/ci-size-report.yml: publish-baseline no longer
  gates on the aggregate workflow_run.conclusion. It now queries the
  specific build / upload-artifacts job's conclusion via gh api repos/{repo}/actions/runs/{run_id}/jobs and only proceeds if that job
  succeeded — decoupling baseline publishing from the unrelated Release
  job's reliability.
• Distinguishes "job not found" (e.g. a future rename of the caller/callee
  job names) from "job failed", warning louder on the former since that's
  a workflow-structure mismatch rather than an expected build failure —
  and is the same silent-failure class as the bug this PR fixes.

Testing

• Diagnosed against real CI data: gh run view on the actual failing
  release/9.1 push run showed every build job (build (0)..build (14), upload-artifacts, etc.) as success and only the Release job
  as failure ("Bad credentials"), confirming the aggregate-conclusion
  gate was the root cause.
• Verified no size-baseline-release/9.1 or size-baseline-master
  release exists yet in iNavFlight/pr-test-builds, consistent with
  publish-baseline never having successfully run.
• YAML syntax validated (python3 -c "import yaml; yaml.safe_load(...)").
• Can't fully execute a workflow_run-triggered workflow locally; will
  confirm live once merged and a subsequent push to release/9.1 (or
  master, since workflow_run always uses the default branch's copy of
  this file) triggers it.

Code Review

Reviewed with the inav-code-review agent — approved, with two minor
observability suggestions (both addressed): clarified the actions: read
permission comment, and upgraded the "job not found" case to a warning
instead of a notice.

Related

Continues the size-diff PR comment feature from #11791/#11794/#11795/#11796/#11797.

[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

Fix size baseline publishing by gating on build job success, not run conclusion

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Stop baseline publishing from being blocked by unrelated nightly Release job failures.
• Query the triggering run’s job list and require build/upload-artifacts success.
• Add explicit warnings when the expected job name is missing to avoid silent breakage.

Diagram

graph TD
  A["workflow_run: Build pre-release (push)"] --> B["Check build job conclusion"] --> C{{"GitHub Jobs API"}} --> D{"build / upload-artifacts success?"} --> E[("Artifacts: size-report + branch-name")] --> F["Publish baseline"] --> G["pr-test-builds: size-baseline-* release"]
  D --> H["Skip baseline (warn/notice)"]

  subgraph Legend
    direction LR
    _job["Workflow step/job"] ~~~ _ext{{"GitHub API"}} ~~~ _art[("Artifacts")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Make the nightly Release job non-blocking

• ➕ Restores overall workflow_run.conclusion == success semantics
• ➕ Avoids extra API calls and parsing logic in publish-baseline
• ➖ Hides real nightly publishing failures (reduced signal)
• ➖ Requires changing the producer workflow (nightly-build.yml), not the consumer

2. Gate on artifact existence instead of job conclusion

• ➕ More robust to job renames (only depends on artifact names)
• ➕ Directly checks the actual prerequisite for publishing
• ➖ Harder to differentiate ‘build failed’ vs ‘workflow structure changed’
• ➖ Still needs extra logic; artifact download failure modes can be noisier

3. Split nightly publishing into a separate workflow

• ➕ Eliminates coupling between build artifacts and release publishing outcomes
• ➕ Simplifies gating logic across downstream workflows
• ➖ Bigger CI refactor and coordination risk
• ➖ More moving parts and triggers to maintain

Recommendation: Proceed with the PR’s current approach: checking the specific artifact-producing job’s conclusion is a minimal, targeted fix that preserves visibility into Release job failures while ensuring baseline publishing runs when the required artifacts are successfully produced. The added ‘job not found’ warning also directly addresses the previous silent-failure class.

Files changed (1) +36 / -3

Bug fix (1) +36 / -3

ci-size-report.ymlGate publish-baseline on build/upload-artifacts job success via GitHub API +36/-3

Gate publish-baseline on build/upload-artifacts job success via GitHub API

• Removes the dependency on the overall triggering workflow run conclusion and adds a step that queries the run’s job list to verify 'build / upload-artifacts' succeeded. Subsequent artifact downloads and baseline publishing now run only when this check passes, with a stronger warning when the expected job name is missing.

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

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

Code Review by Qodo

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

1. Multi-match conclusion mishandled 🐞 Bug ≡ Correctness

Description

Check build job succeeded captures all matching job conclusions into a single variable, but then
compares it as if it were a single scalar value. If more than one build / upload-artifacts job
entry is returned, CONCLUSION becomes multi-valued and the step will incorrectly skip baseline
publishing even when the relevant job succeeded.

Code

.github/workflows/ci-size-report.yml[R60-61]

+          CONCLUSION=$(gh api "repos/${{ github.repository }}/actions/runs/${RUN_ID}/jobs" --paginate \
+            --jq '.jobs[] | select(.name == "build / upload-artifacts") | .conclusion')

Evidence

The jq filter selects every job with the given name and emits .conclusion for each; the script
then treats the captured output as a single value when checking for emptiness and comparing to
success, so multiple outputs will not equal success and will trigger the skip path.

.github/workflows/ci-size-report.yml[60-73]
docs/development/release-create.md[508-512]

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 workflow stores the output of a jq filter that can emit multiple results into `CONCLUSION`, then compares it to the string `success`. If multiple matches exist, the comparison fails and baseline publishing is skipped.

### Issue Context
This job is intended to be a robust gate for baseline publishing; it should deterministically select exactly one conclusion (e.g., the latest/most relevant matching job) and/or explicitly detect and handle multiple matches.

### Fix Focus Areas
- .github/workflows/ci-size-report.yml[60-73]

### Suggested fix
Update the jq query to return exactly one value (or explicitly error/warn on multiple), for example:
- Use jq to select the most recent matching job (e.g., `max_by(.completed_at)` or similar) and output only its `.conclusion`, or
- Collect matches into an array and:
 - if length==0: warn + proceed=false
 - if length>1: warn about ambiguity, choose the latest deterministically
 - else: use the single conclusion

This ensures `CONCLUSION` is always a single scalar (`success`, `failure`, `skipped`, etc.) before the string comparison.

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

---

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

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

1. Multi-match conclusion mishandled 🐞 Bug ≡ Correctness

Check build job succeeded captures all matching job conclusions into a single variable, but then
compares it as if it were a single scalar value. If more than one build / upload-artifacts job
entry is returned, CONCLUSION becomes multi-valued and the step will incorrectly skip baseline
publishing even when the relevant job succeeded.

Agent Prompt

### Issue description
The workflow stores the output of a jq filter that can emit multiple results into `CONCLUSION`, then compares it to the string `success`. If multiple matches exist, the comparison fails and baseline publishing is skipped.

### Issue Context
This job is intended to be a robust gate for baseline publishing; it should deterministically select exactly one conclusion (e.g., the latest/most relevant matching job) and/or explicitly detect and handle multiple matches.

### Fix Focus Areas
- .github/workflows/ci-size-report.yml[60-73]

### Suggested fix
Update the jq query to return exactly one value (or explicitly error/warn on multiple), for example:
- Use jq to select the most recent matching job (e.g., `max_by(.completed_at)` or similar) and output only its `.conclusion`, or
- Collect matches into an array and:
  - if length==0: warn + proceed=false
  - if length>1: warn about ambiguity, choose the latest deterministically
  - else: use the single conclusion

This ensures `CONCLUSION` is always a single scalar (`success`, `failure`, `skipped`, etc.) before the string comparison.

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

[github-actions]

Test firmware build ready — commit fa7a86f

Download firmware for PR #11801

244 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

[github-actions]

RAM / Flash usage vs. base branch — commit fa7a86f

No size baseline is available yet for this PR's base branch (first run after this feature shipped, or a new branch). This comment will show deltas once a baseline exists.

Target	Flash Δ	RAM Δ
MATEKF405	624935 B (no baseline)	133256 B (no baseline)
MATEKF722	468307 B (no baseline)	123312 B (no baseline)
MATEKF765	645875 B (no baseline)	138768 B (no baseline)
MATEKH743	664155 B (no baseline)	139776 B (no baseline)

See RAM/flash optimization guide for techniques to reduce usage.