Skip to content

[WIP] Write a JUnit XML report from databricks pipelines test - #7273

Draft
tharunbhuk-db wants to merge 27 commits into
databricks:mainfrom
tharunbhuk-db:tharun/pipelines-test-pr3-junit
Draft

tharunbhuk-db wants to merge 27 commits into
databricks:mainfrom
tharunbhuk-db:tharun/pipelines-test-pr3-junit

Conversation

@tharunbhuk-db

@tharunbhuk-db tharunbhuk-db commented Oct 30, 2026 •

Copy link
Copy Markdown

Stack 3/4: #7271 command · #7272 output · #7273 JUnit · #7274 bundles. Builds on #7272.
This PR's changes: tharunbhuk-db/cli@tharun/pipelines-test-pr2-output...tharun/pipelines-test-pr3-junit
Design doc: https://docs.google.com/document/d/1atW-JG_hQu-G-YX-m1M7OodNZdH7LMc9H7CBlQAv5gw/edit

Changes

  • Add --junit-xml <path>, which writes one testcase per collected test case, with its outcome and duration. Cases are named relative to the project folder, as pytest names them, so the names do not depend on the working directory.
  • A case without a final outcome is an error. A run without tests, an incomplete run, a timeout or a late update failure adds a failing entry that names the cause.
  • Every exit writes the report, including invalid flags and a --resume of an update that is not a test update, so an older report is never left behind. --junit-xml cannot be used with --no-wait, and the --resume command printed after a timeout keeps --junit-xml so that it replaces the partial report.

Why

CI systems read JUnit XML to show test results and to gate merges.

Tests

  • Unit tests for the case names, the outcome mapping, the failing entries and write errors.
  • Acceptance tests that compare the written reports (out.*.xml) for a passing run, each failing outcome, invalid flags, a timeout and resume, and errors before the update is read.

This pull request and its description were written by Isaac.

tharunbhuk-db and others added 4 commits October 30, 2026 18:22
Submits a test-only pipeline update with optional test selections and
pytest arguments. Relative selections resolve to deployed workspace
paths through the bundle sync root, or against the pipeline's root_path
when the pipeline is identified with --pipeline-id. Only -k and -m are
accepted in --pytest-arg.

Co-authored-by: Isaac <no-reply@databricks.com>
Cover each rejected pytest option with a unit test, and add an acceptance
case for `--pytest-arg VALUE`, which keeps commas and spaces.

Co-authored-by: Isaac <no-reply@databricks.com>
The service names a test case relative to pytest's rootdir: the deepest
folder that holds the pipeline's root_path and every test source, or,
without a root_path, the folder of every test source. A test ID copied
from the results now runs that test again in any project layout.

A relative selection that exists locally still maps to its deployed
path. Any other relative selection resolves against that folder, which
the command reads from the deployed pipeline. With --pipeline-id, all
relative selections resolve against it.

Co-authored-by: Isaac <no-reply@databricks.com>
…nd preview

A local test path mapped to workspace.file_path in every sync mode. A
source-linked deployment runs the source files, so a local path now maps
under the sync root, as TranslatePaths maps resource paths. An immutable
deployment runs a snapshot whose path the command does not know, so a
local path is an error there that points to test IDs and workspace
paths, which still work.

The folder of test IDs is read once, and only when a selection is a
relative path. Paths in errors use forward slashes. The Short text
starts with *Preview*, like other preview commands.

Tests: the option list covers each rejected form once, and a folder test
source without root_path has its parent as the folder of test IDs, as
the service computes it.

Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution! This pull request was opened from a fork.

If you're a member of the Databricks organization, please request access to the cli-contrib team and open your pull request from a branch in this repository instead of a fork — fork PRs don't run integration tests automatically and have reduced CI access.

If you're an external contributor, no action is needed; a maintainer will review your pull request.

@github-actions github-actions Bot added the DABs DABs related issues label Oct 30, 2026
@tharunbhuk-db
tharunbhuk-db force-pushed the tharun/pipelines-test-pr3-junit branch from b165bb5 to 20877cc Compare October 30, 2026 19:02
@tharunbhuk-db tharunbhuk-db changed the title Write a JUnit XML report from databricks pipelines test [WIP] Write a JUnit XML report from databricks pipelines test Oct 30, 2026
@tharunbhuk-db
tharunbhuk-db force-pushed the tharun/pipelines-test-pr3-junit branch from 20877cc to b6de2c2 Compare October 31, 2026 18:58
@github-actions

Copy link
Copy Markdown
Contributor

An authorized user can trigger integration tests manually by following the instructions below:

Trigger:
go/deco-tests-run/cli

Inputs:

  • PR number: 7273
  • Commit SHA: b6de2c2163bca7c1ca6c9f0e229ba58fc506a945

Checks will be approved automatically on success.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

DABs DABs related issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant