Real checks, on real pull requests.
Not a mockup. These are the actual checks EmbedCI posted on pull requests in our demo repo — the same firmware, with different budgets, producing a clean pass and a clear fail.
All budgets met → green.
The firmware builds, boots in Renode, passes its behavioral tests, and clears every gate. The check reports flash/RAM footprint, stack high-water, the MISRA findings table, and each gate's limit vs. actual — all on the PR.
View this PR on GitHub →
Over budget → the merge is blocked.
Same firmware, tighter limits. Two gates fail — Flash over its 1% cap and MISRA over its 0 budget — so the check goes red. Each failing gate names its limit and actual value, so a developer sees exactly what to fix.
View this PR on GitHub →
Same firmware. Different verdict.
The only difference between these two runs is the budgets set in .embedci.yml. That's the point: you decide what "good" means for your firmware, and EmbedCI enforces it on every pull request — automatically, with no hardware in the loop.
Validated end-to-end on stm32f4_disco today. The checks above are live and viewable on the linked pull requests.