Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Build History Timeline Block for Solid

A CI build history: a strip of thirty builds (pass, fail, running) over a rail of the last eight, with the first failing build, the last green one and the commits to inspect worked out, and a details list for the selected build.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Find the build where it went red, and what changed in it, with this build history timeline for Solid with Ark UI. It is written for Bisectly, a fictional CI service, and one repository, storefront-web. A hairline frame with a plus mark on each corner holds a strip of the last thirty builds: a filled cell for a pass, a cell with a cross for a failure, a dashed ring for the build still running. Each cell is a radio button, so the arrow keys move along the strip and the strip scrolls sideways in its own region on a phone. Under it one sentence is worked out from the data: "First failing build #1843, last green #1842: 4 commits to inspect", with a "Show #1843" button that selects it. A rail below lists the latest eight builds with the number, the short commit hash in mono, the trigger, the duration and the status in words with a glyph, and a list at the end shows the selected build in full: status, the step it ended on, commit, trigger, start, duration and how many commits were pushed since the build before. Selecting from the strip or the rail is the one local state, and a polite status line says what is selected. It is built from Guides, Button and lucide icons, with a CSS entrance only. For CI dashboards, release pages and deploy histories. The builds are example data.

FAQ

How do I change the builds?

Set the letters in STATES at the top of the file, one per build, oldest first: p for a pass, f for a fail and r for a build still running. The number, hash, trigger, duration, start time and commit message of each build come from small helpers over its position and the MESSAGES list, so a build is one letter and one line. Replace those helpers with your own records when you wire it up; the strip, the rail and the sentence read the same Build objects.

How is the first failing build worked out?

firstBadOf walks the builds from the newest back and remembers the oldest failure of the current red run, stopping at the first pass. A running build is skipped. The last green build is the one before it, and the commits to inspect are the commits pushed with the first failing build. An earlier, isolated failure does not move it.

Why are the cells radio buttons?

A native radio group gives you the arrow keys, one tab stop and a name for each cell for free, so thirty cells do not mean thirty tab stops. Each cell has screen reader text ("Build 1843, failed"), and the strip sits in a left to right box in every language, like a chart.

What stays in the page, and how do I use real builds?

Only the selection, which is local state. Nothing is fetched and no build is re-run. To use real builds, map your CI service's runs to the Build shape; the sentence, the details and the status line follow from the data.

How does it look on a phone?

The strip scrolls sideways and the selected cell keeps its ring. Each rail row folds its trigger and duration into a second line under the number, hash and status, and the details list is two columns wide.