DriftFence Docker example
Repo-history example

build-push-action: two build-argument changes the repo's own checks missed.

In a measured replay of five real commits from docker/build-push-action, the same selected checks passed in standard CI every time. DriftFence stayed quiet for one commit, then flagged one new call forwarding change and one later allow forwarding change.

With approved build-argument behavior fixed in Git, DriftFence would have started flagging the moment the action began forwarding call into --call, then tightened again when allow stopped using one joined string and started emitting one flag per value.

See the first flagged change Back to results summary
First divergence

The action started forwarding call into --call.

The first replayed commit in this window stayed conforming. On the second commit, the action started forwarding the selected build evaluation mode into --call, while the same selected checks still passed in standard CI.

Blocked case

The selected call mode stopped staying null.

In the approved baseline, the selected evaluation mode did not forward into the final build arguments. After the feature landed, the action started forwarding check into --call.

DriftFence report
Scenario
docker.build-push-action.context.call-input
Expected
output.callForwarded = null
Observed
output.callForwarded = "check"
Classification
violating

Later in the same slice, allow changed from one joined string to one --allow flag per value. The existing builder control did not trigger DriftFence anywhere in the five-commit window.

Across the replay window

One quiet commit, then two clear build-argument onsets.

This replay is legible because the slice starts with one quiet merge, then DriftFence catches call and later allow while builder stays conforming throughout.

Quiet commit first

One earlier merge stayed conforming

  • 5e99dac merged publish-immutable-action changes without altering the protected argument-forwarding behavior.
  • That first replayed commit kept all three selected workflows conforming.
Then the onset

call started forwarding into the final args

  • 75ffdcc added the new call input.
  • The selected evaluation mode started flowing into --call.
  • DriftFence flagged that change while the same checks stayed green.
Later in the slice

allow changed and builder stayed quiet

  • b5e932e stopped emitting one joined --allow value and started emitting one flag per requested entitlement.
  • The existing builder forwarding control stayed conforming across the whole slice.
Method

How it was measured.

This replay fixes one build-argument baseline, reruns the same selected tests on each commit, and records two onset units because call and later allow diverged on separate commits.

  • Replay size: 5 commits
  • Fixed workflows: call, allow, and builder
  • 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 0 matched quiet controls
Source material

Method and source files.

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

Measurement notes

The benchmark results log records the completed build-push-action window, including the replay size, outcome mix, and the two forwarding onsets.

Fixed test plan

The replay definition fixes the three build-argument workflows and the exact late-November 2024 replay window used here.

Related pages

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