CI: budgets for image size, memory at rest, startup and delivery latency, so lean stays lean
- Dominant language
- C#
- Stars
- 6
- Forks
- 7
- Avg merge
- 4h 42m
- Merged PRs (30d)
- 307
Description
Arnel, 14 September 2026: the goal is useful, mature, lean and optimized. Lean work (#745, #746, #747) and measured tuning (#798, #799) only stay done if something notices when weight comes back. Today nothing does: an added package, a heavier base image or a new hosted service can grow the image or the memory at rest and CI stays green.
## Change
A CI job on every pull request that builds the production image and records:
- **Image size**, compressed and uncompressed, for `barako-cms` (and the same job in barakoBrew and barakoPress for their images).
- **Memory at rest**: the API started against Postgres with the quickstart settings, idle for 60 seconds, then the container's resident memory.
- **Startup time** to a passing readiness check.
- **Delivery latency** from `scripts/delivery-load.py` (#799) at a low fixed rate: p50 and p95 for the list, an entry by slug, and the site entry.
Each has a budget in a committed file (`perf-budget.json`), set from master's current numbers plus a margin. A pull request that exceeds a budget fails with the before and after numbers in the job summary. Raising a budget is a change to that file, so it is reviewed on purpose, and the pull request says why.
The numbers from master are kept as a history (an artifact per run, or a small committed CSV updated by the release workflow), so a slow creep across many small pull requests shows up too.
## Done when
- A pull request that adds a large unused package fails the image size budget with both numbers shown.
- A pull request that lowers memory at rest shows the improvement in the summary without failing.
- The job adds no more than five minutes to CI, and runs on arm64 as well as amd64 since the images ship both.
Contributor guide
Research direction
Start by locating the existing CI entry points for building the production images and running the API against Postgres, then inspect scripts/delivery-load.py and define the committed perf-budget.json values from current master numbers. Done means pull requests report image size, idle memory, startup, and delivery p50/p95 for both architectures, fail with before-and-after values when budgets are exceeded, retain history, and stay within five additional minutes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, postgresql, python
- Domain
- ci-cd, devops, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100