Repo-history example

`release-please-action`: one release-config change the repo's own checks missed.

In a measured replay of nine real commits from googleapis/release-please-action, the same selected checks passed in standard CI every time. DriftFence stayed quiet through eight commits, then flagged one release-config forwarding change.

With approved release-config behavior fixed in Git, DriftFence would have started flagging the moment the action began forwarding versioning-strategy and release-as into manifest construction.

See the first flagged change Back to results summary

First divergence

New release-config inputs started forwarding into the manifest build.

The first eight commits in this window stayed conforming. On the ninth commit, the action started forwarding both versioning-strategy and release-as into Manifest.fromConfig, while the same selected checks still passed in standard CI.

Blocked case

`versioning-strategy` and `release-as` stopped staying null.

In the approved baseline, both values stayed unset in the selected release-type config path. After the feature landed, the action started forwarding default for versioning-strategy and 2.0.0 for release-as.

DriftFence report

Scenario

release-please-action.release.config.versioning-strategy

Expected

output.versioningForwarded = null

Observed

output.versioningForwarded = "default"

Classification

violating

release-as changed on the same commit from null to 2.0.0. The target-branch and fork controls did not trigger DriftFence on the same nine-commit slice.

Across the replay window

Eight quiet commits, then one clear release-config onset.

This replay is stronger than a recurring-all-red window because the onset comes after eight quiet commits on the same selected test surface and keeps two matched quiet controls.

Quiet commits first

Eight unrelated commits stayed conforming

Release automation, README, output docs, test cleanup, and a Mocha bump all stayed quiet.
Even the later changelog-host fix stayed conforming on this selected release-type config surface.
None of those commits changed the protected forwarding behavior.

Then the onset

One feature added two new forwarded values

ee0f5ba added versioning-strategy and release-as.
Both values started flowing into Manifest.fromConfig.
DriftFence flagged that change while the same checks stayed green.

Nearby controls

Two comparison cases stayed quiet

target-branch stayed conforming across the whole slice.
fork stayed conforming too.
Both controls stayed quiet on the same selected test surface.

Method

How it was measured.

This replay fixes one release-config baseline, reruns the same selected tests on each commit, and counts the onset once because only one commit in the window drifted.

Replay size: 9 commits
Fixed workflows: versioning-strategy, release-as, target-branch, and fork
The same selected checks reran on every commit in the window
DriftFence reran on every commit with the same approved baseline
Longitudinal follow-up found 2 onset units and 4 matched quiet controls

Source material

Method and source files.

The links below show the benchmark notes and pinned replay plan for this release-action example.

Measurement notes

The benchmark results log records the completed release-please-action window, including the replay size, outcome mix, and first flagged change.

Benchmark results

Fixed test plan

The replay definition fixes the four release-config workflows and the exact September 2025 replay window used here.

See the product, results, pricing, and trust pages alongside this release-action example.