shadcn.io is not affiliated with official shadcn/ui
Pipeline Runner Command Menu Block for Ark UI
A CI service's command menu shown open under a repository's Pipelines tab: six pipelines with their last result as a word and glyph, and Enter runs one, ticking through Build, Test, Package and Deploy.
Installation
Overview
Run a pipeline and watch its stages with this CI command menu for React with Ark UI. It opens from the Pipelines tab of a repository in Buildhollow, a CI service, whose header holds an outline field with its ⌘ K cap, and the repository's run list is drawn under a soft scrim inside a hairline frame with a plus mark on each corner. The menu is the catalog Command and hangs from the tab at the start: six pipelines, each with its last result as a word and a glyph. Enter runs one and the row ticks through Build, Test, Package and Deploy, one step every 300 ms, then ends Passed or Failed, and a failing pipeline stops at its own step. The menu stays open so the run can be watched, the run list behind it gains the run, and on a phone the steps shrink to initials while the row's second line names the full step. For preview the menu is drawn open in place when the page loads; the field, or Ctrl or ⌘ K while focus is in the block, opens the real command dialog with the same pipelines and run. For CI dashboards, release tools and any list of jobs you start from the keyboard.
FAQ
Why is the menu already open, and what do I keep?
So you can see it without a click. On load the menu is the Command drawn inline over a picture of the repository, in a plain shell that is not modal, so nothing is trapped, hidden or focused and the page around the preview keeps working. The header's field opens the real command dialog, modal, with its focus trap, Escape and focus return, and the inline copy stays closed until a reload. Both show the same Palette and share the block's state, so a run started in the copy keeps ticking in the dialog. In your app keep the dialog and drop the copy: the "in-place" state, the scrim with its shell and the Escape and blur effects.
How does a run tick through its steps?
A run is two numbers, the pipeline and the step it is on. One timer moves the step on every 300 ms; on the pipeline's last step, or the step it is set to fail at, the timer ends the run instead, writes the result and the fixed time onto the pipeline and adds a numbered run to the list. Only one pipeline runs at a time, and pressing Enter on another says which one is still running. Reduced motion stops the spinner turning, but the steps still advance, because they are data.
Why does a run always end the same way?
Each pipeline carries its own outcome as data, and Release train and Mobile build are set to fail, at Test and at Package. A demo that failed at random would make the page differ from one load to the next. The result is a word and a glyph, never a colour, so it reads the same in any theme.
What stays local, and how do I wire it?
All of it. Nothing is built, tested or deployed and the status line says "Simulated run". In your app replace the timer with your CI service's run: start it from pick, feed the step and the outcome from its events or a poll into run, and keep finish for the result.
What does a phone show?
The menu docks to the top of the stage, the steps show as their initials (B, T, P, D) and the result badge is dropped, while the row's second line names the whole step and its place, such as "Running Test, step 2 of 4". The line is on every screen; the strip of step names only appears from the small breakpoint up.
Is it accessible from the keyboard?
Yes. Type to filter by name or branch, the arrow keys move through the rows, Enter runs the highlighted pipeline and Escape closes the menu with focus back on the header's field; Ctrl or ⌘ K opens the dialog while focus is inside the block, and only then. A running row is marked aria-busy and the status line speaks the start and the result once each. The rows are options of a combobox and the first is highlighted when it opens.