Size reports

[ivmarkov]

This is inspired by the rs-matter (and Matter C++ SDK) size reporting which I find quite nice.
See how it looks here.

But rather than relying on a 3K LOCs of Python code copied from Matter C++ (as rs-matter still does), this PR uses a new elfsize command installable with cargo install elfsize and maintained in the embuild utility.

Here, a comparison with cargo size.

How this differs from esp-hal's /test-size

(I asked Fable to compare, let me know if something is off.)

Same core idea (build base and head in one job, diff the ELFs, comment), with these changes:

• Automatic and fork-safe. Runs on every PR with a read-only token; a separate workflow_run job posts the comment from the base repo. No /test-size command, no trust list.
• Correct baseline. Head is the merge commit, base is pull_request.base.sha. esp-hal diffs against main HEAD at dispatch time, which picks up unrelated changes when main has moved.
• Correct sections. FLASH is the file-backed size of all PT_LOAD segments, i.e. the actual flash image. esp-hal's bloaty filter drops .rodata entirely. RAM is a section prefix list, with .stack excluded because esp-hal sizes it as "whatever is left".
• One report for everything. All examples on all chips in one comment: increases above the threshold first, then all regions and all sections collapsed. esp-hal posts one bloaty table per chip.
• Tooling. The elfsize crate from embuild, ~300 lines of Rust over xmas-elf, installed with cargo install elfsize. No bloaty action, no llvm-tools (which the espup Xtensa toolchain lacks).
• Not done. No size history across commits; each PR is measured against its own base only.

[ivmarkov]

@bjoernQ Ready for review.

I'm a bit concerned with Fable saying "esp-hal's bloaty filter drops .rodata entirely". Could that really be the case?

[Copilot]

🔵 Needs a closer look

The changes add security-sensitive workflow_run CI with write permissions and depend on an elfsize tool whose publishing state is unverifiable here, so human review is warranted.

Pull request overview

This PR adds automated firmware size reporting to CI, inspired by rs-matter's size reporting. It introduces two workflows that build each MCU family's examples at both the PR's merge commit and the base branch, measure the ELFs with the new elfsize tool, and post a single consolidated diff comment on the PR using a fork-safe workflow_run pattern. It also adds the OpenThread version string to the initialization log line.

Changes:

• New size.yml workflow: builds examples for esp32c6/esp32h2/nrf52840 at head and base, measures with elfsize, and uploads a report artifact.
• New size-comment.yml workflow: runs on workflow_run completion with a write token to post/update the size report as a PR comment without executing PR code (fork-safe).
• lib.rs: logs the OpenThread version string alongside the existing "instance initialized" message.

File summaries

File	Description
.github/workflows/size.yml	Adds the build-and-measure job matrix plus a report job producing the size artifact.
.github/workflows/size-comment.yml	Adds the fork-safe workflow_run job that posts/updates the size report PR comment.
openthread/src/lib.rs	Enriches the initialization log with the OpenThread version via Self::version().

Key notes: The lib.rs change is correct (version() returns &'static str). The main issues found are an inline comment in size.yml that describes installing elfsize from a git branch while the command uses cargo install elfsize (crates.io) — which fails if the crate is unpublished — and a hardcoded 0.2% threshold in size-comment.yml that duplicates SIZE_WARN_PERCENT.

Review details

Suppressed comments (1)

.github/workflows/size.yml:154

• Same inconsistency as in the size job: the comment states elfsize is "Not yet published" and "built from the size-check branch of embuild", but the command cargo install elfsize installs the published crate from crates.io. If the crate is not published this step fails; otherwise the comment is stale. Reconcile the comment and the command.

      # Not yet published; until then, built from the `size-check` branch of embuild
      - name: Install elfsize
        run: cargo install elfsize

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[bjoernQ]

I'm a bit concerned with Fable saying "esp-hal's bloaty filter drops .rodata entirely". Could that really be the case?

I'm not too familiar with bloaty but at least it's not listed in https://github.com/esp-rs/esp-hal/blob/e88f8cee26b3bd49449370ebeb9ae7dc18a202a3/.github/workflows/binary-size.yml#L197

Also not sure if we need to do something about e.g. .data.wifi explicitly (no idea how -source-filter exactly matches - wasn't about to find docs)

@JurajSadel might be worth double checking!

[bjoernQ]

LGTM

[ivmarkov]

LGTM

Thanks, will open a similar one for mbedtls-rs later today.