github Institut-du-Numerique-Responsable/perf-sentinel v0.38.0

latest release: chart-v0.38.0
2 hours ago

What's new in v0.38.0

v0.38.0 is about a question a team review asks and the Hub could not answer: what does this finding cost in CO₂? The daemon already prices a batch's avoidable I/O in grams when green scoring is on, but that figure stayed inside the batch report. The detection ledger now keeps it, day by day, and hands it to PerfSentinelHub, whose review recap in Hub 0.9.0 turns it into an order of magnitude per finding.

The day's avoidable carbon, next to its counts

Each days object of GET /api/detections, and of the ledger push to the Hub, gains four keys: avoidable_gco2 and avoidable_gco2_low, the operational avoidable CO₂ of the day's batches (green_summary.co2.avoidable.mid and .low, in gCO₂eq), plus avoidable_io_ops and total_io_ops for the same batches. Every scored batch feeds them, including a batch with no finding, which adds to total_io_ops only. That keeps avoidable_io_ops / total_io_ops an honest waste ratio for the day. The four keys travel together or not at all, and they are absent when green scoring is off or no batch resolved a region, so a missing region never reads as zero grams. A day the Hub already acknowledged is sent again as soon as its carbon moves, even with no new detection. The new lab scenario detection-carbon checks all of this end to end against a fake Hub.

Grams per avoidable operation, not a new measurement

avoidable_gco2 / avoidable_io_ops is the day's grams per avoidable I/O operation, the coefficient the Hub multiplies by a finding's detected volume. It is an order of magnitude only: a finding's extra_io_ops is not deduplicated across findings the way a batch's avoidable_io_ops is. Like the detection counts, the four sums cover the [daemon] sampling_rate share of the traces, so the ratios hold as they are and an absolute figure needs dividing by the rate.

Smaller changes

  • The official public example disclosure, example-official-public-G2.json, moves to perf-sentinel 0.37.1 on schema perf-sentinel-report/v1.8, with the published binary's hash and a rebaked content_hash.

Upgrade impact

  • Upgrade PerfSentinelHub to 0.9.0 before or with this daemon. An older Hub drops the four new keys, and a day it already acknowledged is not sent again until it changes, so its carbon would be lost for good.
  • Nothing to configure. The keys appear on their own when green scoring is on and a region resolves.
  • /api/detections days carry four more optional keys. A reader that refuses unknown members must accept them.
  • No configuration key is added or removed, no route or metric changes, the acknowledgment signatures and the detection verdicts are untouched, the disclosure schema stays v1.8, the embedded reference data keeps its vintages, and MSRV stays 1.99.1.

Full detail in CHANGELOG.md.

Verifying this release

# Binary integrity via SLSA build provenance attestation (Build Level 2)
gh attestation verify perf-sentinel-linux-amd64 \
  --repo Institut-du-Numerique-Responsable/perf-sentinel

# A periodic disclosure produced by this binary, with its attestation and bundle
perf-sentinel verify-hash --report perf-sentinel-report.json \
  --attestation perf-sentinel-report.intoto.jsonl --bundle perf-sentinel-report.sig \
  --expected-identity "https://github.com/Institut-du-Numerique-Responsable/perf-sentinel/.github/workflows/release.yml@refs/tags/v0.38.0" \
  --expected-issuer "https://token.actions.githubusercontent.com" \
  --verify-binary ./perf-sentinel-linux-amd64

gh CLI 2.49 or newer required for gh attestation verify. Releases up to v0.26.2 were attested under robintra/perf-sentinel and keep their own --repo and identity.

Don't miss a new perf-sentinel release

NewReleases is sending notifications on new releases.