• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

dangernoodle-io / breadboard / 30972634497
97%

Build:
DEFAULT BRANCH: main
Ran 05 Aug 2026 03:36AM UTC
Jobs 1
Files 216
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

05 Aug 2026 03:34AM UTC coverage: 96.928%. Remained the same
30972634497

push

github

web-flow
build: wire the warning_fence families to live CI build output (B1-1420 PR2) (#1231)

The original snapshot design (a committed report file, regenerated only
when a human remembered to) let the fence go green forever the moment
nobody re-ran the generator -- it validated a committed file, not the
code. Rewired to live build output instead: the diagnostics were
already being produced in CI, just discarded.

- Split into two families, warning_fence_host / warning_fence_firmware
  (scripts/bbtool/fence/warning_fence_{host,firmware}.py, shared
  parsing + report contract in fence/_gcc_warnings.py): each is
  enforced by the CI job that already compiles for that target with a
  different toolchain (.github/workflows/build.yml's `test` job for
  host, `smoke` job's `esp32` matrix leg for firmware), so a single
  combined family would wrongly hard-fail in whichever job's report is
  absent from that job's own checkout.
- scripts/warn_scan.sh runs the real `-Wall -Wno-error` build (still
  never touching platformio.ini's or examples/smoke/CMakeLists.txt's
  committed -Werror -- temporary overrides only) and writes a report
  with a mandatory "# bb-warn-scan v1 target=<T> build_exit=<N>"
  header line, then the SAME job immediately fence-checks that live
  output -- a new warning fails the build where it's produced.
- Fail-closed: a report that is missing, empty, unreadable, has a
  malformed header, or whose build_exit is non-zero (the capture build
  itself broke) is never treated as "zero warnings". Gated on
  BB_WARNING_FENCE_STRICT=1, exported only by the two enforcing CI
  steps -- deliberately narrower than the generic CI env var GitHub
  Actions sets on every job, since the `check` job (bare `make check`,
  no PlatformIO) can never produce a report and would otherwise
  hard-fail on every single run rather than only on a regression.
  Outside those two steps (the `check` job, `make test-py`, a dev
  machine without the toolchain) it's a loud SKIP, neve... (continued)

8391 of 8950 branches covered (93.75%)

Branch coverage included in aggregate %.

14138 of 14293 relevant lines covered (98.92%)

2606.57 hits per line

Jobs
ID Job ID Ran Files Coverage
1 30972634497.1 05 Aug 2026 03:36AM UTC 216
96.93
GitHub Action Run
Source Files on build 30972634497
  • Tree
  • List 216
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #30972634497
  • 70c5f1a2 on github
  • Prev Build on main (#30970481757)
  • Next Build on main (#30974895952)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc