The Builds page
Builds is the organization-wide history of every build you have run. It answers the question a single project’s Build tab cannot: what has been built lately, across all your projects, and what became of it. Runs are reviewed here. They are never started here.
The page carries a Preview badge in its header. Builds is released to organizations enrolled in preview access, so if yours is not enrolled, Builds does not appear in the navigation rail and opening its address takes you back to your dashboard. Ask your DeltaVault contact if you need your organization enrolled.
What the run list shows
Section titled “What the run list shows”The list is one row per build run, and each row reads left to right:
- Status, as a badge: running, succeeded, failed, or committed.
- The project the run belongs to.
- The layers the run covered, comma separated.
- A workspace badge, when the run was scoped to one workspace rather than a whole project.
- When it started, in your local time.
- The summary, right aligned: the artifact count, followed by the failure count when the run has failures.
- The commit hash, its first seven characters, once the run has been committed.
Two filters sit above the list. Project narrows to a single project and defaults to All projects. Status narrows to one state and defaults to All.
The filter capitalizes the four states (Succeeded) while the row badge prints them in lowercase (succeeded). They are the same four states, spelled two ways.
Reaching Builds from inside a project shows only that project’s runs, drops the Project filter, and names the project above the list.
Open a run
Section titled “Open a run”Select any row and that run’s detail opens below the list.
The detail repeats the status, the layers and the start time, then counts what the run produced: the number of artifacts, the number of failures when there are any, and the number of warnings when there are any. To the right you get either the commit hash, once the run has been committed, or a Commit to git button while it has not.
Under that sits the artifact tree: every file the run generated, grouped into folders by its path, each file badged valid, invalid, or error. This is where the deployable bundle becomes something you can actually read, including the generated orchestration definition at databricks/resources/workflows.yml.
Select a file to open it in a drawer. The drawer takes the file’s full path as its title, badges its type and its validation state, lists Validation errors when the file has any, and prints the Rendered content below them with a Copy button.
Two further sections appear only when a run recorded something for them: Platform, for target platform findings, and Validation, for validation findings attributed to a table. A run that recorded neither shows neither, which is the ordinary case.
A succeeded run can still carry failures
Section titled “A succeeded run can still carry failures”This is the part of the page most likely to mislead you, so read it before you trust a green status.
When validation blocks one of your tables, that table is dropped from the build rather than stopping it. The run finishes succeeded, its failure count is not zero, and the tree carries an error placeholder where the table’s file should have been. A run fails outright only when every table in scope was blocked.
So read the failure count, not the status alone. A succeeded run with failures has a hole in it, and Commit to git refuses it until the findings are cleared: an error placeholder is never committed, and there is no override for one. Validation and lint runs explains what those findings are and how to clear them.
Start a build
Section titled “Start a build”You cannot start a build from this page, which is exactly what it tells you when it is empty: No builds yet. Open a project’s Build tab to run one.
Builds run from a project’s Build tab, or from a workspace’s Build action when you want that workspace’s tables alone. Build and deploy your project covers that flow end to end, from the layer picker through to the commit.
Troubleshooting
Section titled “Troubleshooting”- Commit to git is disabled. Hover the button for the reason. Committing needs the editor role, it needs the feature in your plan, and it applies only to a run whose status is succeeded.
- Builds is missing from the navigation rail. Your organization is not enrolled in preview access. Opening the page directly returns you to your dashboard.
- A file carries an error badge. That file never rendered. Open its drawer to read the failure, fix the metadata behind it, and run the build again. A run is a snapshot and is never repaired in place.