Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Pipeline Config Settings Block for React

A pipeline settings window that draws its stages as cards on a canvas, redraws the lines when a stage runs in parallel, and recomputes the total time, with an inspector for each stage.

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

Let people see how a change to a stage changes the whole pipeline, with this pipeline settings window for React with Base UI. A framed window with a plus mark on each corner has a top bar with the one Shine Button, Save pipeline, and a toolbar with Add stage, Undo and Discard. A canvas draws the stages (Install, Lint, Test, Build, Deploy) as cards in columns joined by hairlines in an SVG; a stage that runs in parallel with the previous one stacks in the same column, up to three, and the lines fan out and in again. The cards are real buttons in reading order, so the SVG is only the drawing, and a sentence under the canvas says the order and the total ("Install, then Lint and Test, then Build, then Deploy. At most 23 min: Install 4 + Lint and Test 8 + Build 6 + Deploy 5"): stages in a column share their longest limit and the columns add up. Choosing a stage opens its inspector: a Switch to run it, a Native Select for the trigger, an Input for the time limit, a Switch for parallel and the buttons Earlier, Later and Remove; stages that are off wait in their own row. It's built from Switch, Native Select, Input, Button, Shine Button and Guides, with a CSS entrance only. For a CI or CD service, a release tool or any product with an ordered set of steps.

FAQ

How do I change the stages, triggers and limits?

Edit SAVED (the stages when the page opens: each has an id, a name, whether it is on, its limit in minutes, whether it runs in parallel and its trigger), TRIGGERS and ADDABLE, the three stages Add stage brings. MAX_STAGES and MAX_PARALLEL cap the pipeline and a column. The canvas, the lines, the order sentence and the unsaved count are all worked out from the stages.

How does the canvas redraw, and why is it accessible?

columnsOf turns the stages into columns: a stage that runs in parallel joins the previous column while it has room (three at most), otherwise it starts a new one. The cards are placed in a grid from that, and the SVG, which has the same columns and rows in its coordinates, draws a hairline from every card to every card of the next column. The lines are decoration and hidden from assistive technology; the cards are buttons in an ordered list in the same order, and the sentence under the canvas says it again, so nothing depends on seeing the drawing. A canvas that needs more room than the window has scrolls sideways inside its own focusable region.

What does the total mean?

It is the worst case, not a forecast: every stage may run up to its time limit, stages in a column run at the same time so the column takes its longest limit, and the columns run one after another. A stage that is off takes no time. Nothing runs here: the limits are typed sample data, so replace them with the times from your own history if you want a forecast.

What stays local, and how do I make it real?

Everything. Save keeps the stages in this page's state, Remove and Undo walk a stack in the page, and a reload brings back the starting pipeline. To make it real, store the stage list and each stage's trigger and limit on your server, run the stages from it with the same column rule, and enforce the limits in the runner. Save refuses an empty limit or one outside 1 to 60 minutes, selects the stage and moves focus to its limit field.

How does it look on a phone, and how do I use it with a keyboard?

Below the medium breakpoint the window shows one pane at a time: the canvas becomes a list of stages (a group that runs together is labelled In parallel) and choosing one opens its inspector with a Back button that returns focus to the stage. With a keyboard, Tab runs through the cards in order and then the inspector; the Earlier and Later buttons stay focusable at the ends and say why they do nothing, and after a move focus stays on the pressed button.

  • Pro

    A build settings panel for a static-site host: a preset fills the folder and commands, and a dark terminal writes the build log from the fields, or stops at the error a real runner would give.

  • Pro

    A Git connection settings panel: a provider and repository, a connection that disconnects through an alert dialog, and a branch table that sends patterns to environments, first match wins, with a tester.

  • Pro

    A branch protection settings panel with a branch picker, approval and check rules, merge methods and a tester that says whether a pull request would merge and every reason it would not.

  • Pro

    Build Passed Success

    Builds and deploys

    A confirmation window for a green build: a bar of four stages as wide as their share of the run, a typed terminal log for the chosen stage with a once-only replay, a small artifacts table and a local Deploy this build.

  • Pro

    Deployment Live Success

    Builds and deploys

    A confirmation window for a live deploy: a drawn browser with the real address and a copy button, a group of buttons that redraws the site at desktop, tablet and phone width, and the deploy's facts and four passed checks beside it.

  • Pro

    A feature flag settings panel with ordered targeting rules, a kill switch that asks first, and an Evaluate for a user pane that reads what the flag serves and which rule decided.