Skip to content

fix(disruption): disruption run writes its JUnit report with -o json, and an SLA breach fails through Execute - #397

Merged
bmscomp merged 1 commit into
mainfrom
fix/disruption-run-junit-and-sla-exit
Oct 18, 2026
Merged

bmscomp merged 1 commit into
mainfrom
fix/disruption-run-junit-and-sla-exit

Conversation

@bmscomp

@bmscomp bmscomp commented Oct 18, 2026

Copy link
Copy Markdown
Owner

Item 1.11 of the CLI performance and stability plan (finding F14, its disruption run rows). Independent of the other Wave 1 PRs.

Why

Two kates disruption run paths fail a CI job, both on main (6f4cf61):

  • -o json --output-junit writes no JUnit file. The JSON branch returns at cli/cmd/disruption.go:71-75, and the JUnit report is written only at :115, after the table. A pipeline that wants both the JSON and the JUnit report gets no report.
  • --fail-on-sla-breach calls os.Exit(1) inside RunE (checkSlaExit, :241,244). It prints no message and skips every defer, and an in-process caller ends with it: a test of this path ended the whole test binary.

Changes

cli/cmd/disruption.go:

  • The JUnit report is written right after the run's result arrives, ahead of the -o json branch.
    • With -o json, its note ("JUnit XML written to …" or the write failure) goes to stderr, so stdout stays the JSON alone.
    • In a table the note keeps its place, after the step reports.
  • checkSlaExit returns a silentErr on a breached SLA. Execute ends it with exit 1, as before, and prints nothing more, since the SLA verdict is already on screen or in the JSON.

Tests

Added:

  • TestDisruptionRun_JSONWritesJUnit: -o json --output-junit leaves stdout parseable as the run result, writes a <testsuite> file, and names it on stderr.
  • TestDisruptionRun_SLABreachFailsThroughExecute: with a report whose slaVerdict.violated is true and --fail-on-sla-breach, the command returns the silent error, both with -o table and -o json.

The test backend's report is now a playbookBackend field, and its reset clears --output-junit and --fail-on-sla-breach.

On main's disruption.go, the first test finds no JUnit file, and the second ends the test binary with exit status 1.

Run locally, passing:

  • cd cli && go test ./..., go test -race ./cmd, go vet ./....
  • golangci-lint run --new-from-rev=origin/main ./...: 0 issues.
  • scripts/check-cli-style.sh and scripts/check-cli-compat.sh: OK.
  • The backend suite, which cli/** triggers (Build & Test): this PR touches nothing under kates/. ./mvnw test on main's kates/ tree ran 1,254 tests with 0 failures and 0 errors, once for all of Wave 1.

Skipped locally: govulncheck, as go.mod is unchanged.

CI only: ./mvnw verify with the *IT tests, the Kind and Docker jobs, CodeQL and Trivy.

… and an SLA breach fails through Execute

`kates disruption run -o json --output-junit results.xml` returned from its
JSON branch before the JUnit report was written, so a CI job asking for both
got no file. And --fail-on-sla-breach called os.Exit(1) in the middle of
RunE: no message, every defer skipped, and an in-process caller (a test)
ended with it.

The JUnit report is now written ahead of the JSON branch. Its note goes to
stderr with -o json, so stdout stays the JSON alone, and keeps its place after
the step reports in a table. checkSlaExit returns a silent error, which
Execute ends with exit 1, as before, and no second message, since the verdict
is already printed.
@bmscomp
bmscomp merged commit d9e8069 into main Oct 18, 2026
55 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant