Views

A view is a saved list of pipelines on the Pipelines page. A view picks its pipelines by hand, by rules, or both. Each view keeps its own sort, grouping and layout. The Dashboard page covers the table, the filter bar and the sidebar.

Kinds of viewsCopy Anchor Link

The URL key view selects a view. It is absent for All pipelines. Its value is pinned, the numeric id of a custom view, or config:<key> for a config view. A provider tab on the All view adds provider=<id>.

Create a viewCopy Anchor Link

A custom view starts from one of these entry points:

• New view: the icon button next to the desktop tabs, or the New view button in the Manage views dialog.
• Create view: the sidebar button. It shows only while no custom view exists.
• New sub-view: a button in the sub-view bar, or "New sub-view…" in the context menu of a view.
• From a selection: "New view" in the Select mode bar. The selected pipelines join the new view.
• Add to view: "New view…" in the Add to view dialog.

The dialog is titled "New view", "New sub-view" or Edit <name>.

Saving shows the notification "View created" or "View saved". A name that exists already, an empty name and a name above 60 characters are rejected.

"Edit view…" in the context menu of a view tab or sidebar row opens the dialog again. The "Delete view" button in the dialog, "Delete view" in the context menu and "Delete <name>" in Manage views remove a view.

Members and rulesCopy Anchor Link

A view holds the pipelines added by hand and the pipelines that match its rules.

• By hand: "Add to view…" in the context menu of a pipeline, or the same action in Select mode, opens a dialog with the custom views as a checkbox tree. A row can read "Included by rules" or "Included by sub-views".
• By rules: the Auto-include section of the editor has 4 rules.

A pipeline must match every rule that has a value. Inside one rule, one match is enough. A view without rules matches nothing by rule. An invalid pattern is rejected with Invalid repository pattern "<pattern>".

"Remove from <view>" takes a pipeline out of a view. For a pipeline that joined by a rule, Pipedash remembers the removal for that view and its sub-views. The Members list in the editor also removes and reorders pipelines. A pipeline that no longer exists shows as "Unavailable" there.

Sub-viewsCopy Anchor Link

A custom view can hold sub-views, up to 3 levels deep. A fourth level is rejected with "Views can be nested at most 3 levels deep". A view cannot move inside itself. Config views and the built-in views hold no sub-views.

A parent view includes every pipeline of its sub-views. On the page, a parent lists each non-empty sub-view as a section first, with a folder icon and the pipeline count. The pipelines of a sub-view do not repeat in the sections of the parent. Its own pipelines follow, grouped as the view says. "Open view" in the menu of a sub-view section opens it.

The sub-view bar below the tabs shows the path of parent views and one button per sub-view with its count. The New sub-view button sits there too. The bar appears only when the view has a parent or a sub-view.

Deleting a view asks first. The dialog "Delete view" says that the pipelines stay in Pipedash. The sub-views of the deleted view move up one level. Deleting the open view returns to /pipelines.

DisplayCopy Anchor Link

The View options button in the page header sets how the view looks. The sort, grouping and layout belong to the view, so each view keeps its own.

New views and All pipelines start with name ascending, grouped by repository, as a table. Pinned starts with manual order, no groups, as cards. Manual keeps the order of pinning, or the order set in the Members list. Last Run puts pipelines without a run last. Status sorts by severity, with the most severe first. Ties fall back to the name.

• Headers: the Name, Organization, Status and Provider headers of the table set the sort of the view.
• Cards: a grid of one to four columns that depends on the window width. At 768 px and below the page uses a list of cards and ignores the layout.
• Expand all, Collapse all: open or close every section. They show while the view has sections.
• Expansion: Pipedash saves which sections are open per view, in the localStorage of the browser or app webview. Table sections start closed. Cards, the pinned area and the iPhone list start open. While a filter is active, all sections start open and Pipedash does not save the changes.

The display settings are stored with the view in the database. Every client of the same server sees them. Config views take their display from config.toml, and the View options menu has no sort, grouping or layout group for them.

PinsCopy Anchor Link

A pin keeps something within reach. Pipedash pins three kinds of things.

A pinned repository block holds the pipelines of that repository from every provider. The block has the short repository name and an Unpin <name> button. It follows the filters, and an empty block is left out. A provider tab hides the pinned area.

A shortcut for a view opens /pipelines?view=<id>. A shortcut for a repository opens /pipelines?search=<organization/repository>. Shortcuts follow the order of pinning. A config view cannot be pinned.

An empty Pinned page shows "No pinned workflows" and a Browse pipelines button.

Where pins liveCopy Anchor Link

Pins live in the database of the server or the desktop app, next to the views. Every browser on the same web server sees the same pins. A pin does not depend on the provider name, so a rename keeps it. A storage migration moves pins and remaps the ids. Removing a provider removes its pipelines from the pins. A pin for a pipeline that no longer exists stays stored and stays out of the page.

Earlier versions kept pins and hidden pipelines in the localStorage of the browser. Pipedash imports them once after the update and removes the old keys. Entries that it cannot match to a pipeline are skipped. A failed import keeps the keys and tries again at the next start.

A factory reset deletes all custom views, members and pins, and returns the All and Pinned display settings to their defaults.

Hidden pipelinesCopy Anchor Link

Hide removes a pipeline that is not watched from the list, so it stops counting in the totals and in the sections.

• Hide, Unhide: an entry in the context menu of a workflow, in the Actions menu on the iPhone and in the Select bar.
• Show hidden pipelines: a checkbox item in the View options menu. It shows the number of hidden pipelines, for example Show hidden pipelines (2), and a check mark while on. The item appears only when the view has hidden pipelines or the option is on. The Pinned view does not offer it.
• URL: ?hidden=show. Clear filters removes it.
• All hidden: a view with every pipeline hidden shows "All workflows are hidden" and a Show hidden button.

A pipeline that is a manual member of a view stays visible there, even when hidden. This holds for the Pinned view and the "Pinned" section as well.

Pipedash stores the hidden state in the database. It applies to every view and every client of the same server. config.toml has no setting for it.

Select mode and bulk actionsCopy Anchor Link

The Select button in the page header shows a checkbox on every workflow row or card. It turns into Done while it runs. On the iPhone app, "Select" is in the "More" menu. Changing the view ends the selection.

The bar shows "Select pipelines" or N selected. The buttons stay disabled until something is selected.

On the iPhone app the bar becomes a toolbar at the bottom, titled "Selected pipelines". It has Done and an Actions menu with the same entries.

Cancel runningCopy Anchor Link

"Cancel running…" cancels the unfinished runs of a group. It is in the menu of a repository row, of a sub-view section, of a provider tab and of a provider in the sidebar, and in the Select bar.

The dialog is titled Cancel running in <label> while it searches, and Cancel N runs in <label> when it is ready. The label is the repository, view or provider name, or "N selected pipelines". It reads Looking for running runs… (X of N pipelines) during the search. Only running and pending runs count.

Each pipeline is a group with its provider name. A line below it names the target: the repository, the environment when a run has an env or environment input, the cluster and namespace for ArgoCD, and the namespace for FluxCD and Tekton. Each run row shows the run number, branch, status and start time.

• Providers without cancel: a note says Skipped N running pipelines on <provider>: it can't cancel runs from Pipedash.
• Confirm: the red Cancel N runs button asks the providers one run at a time. Keep running closes the dialog.
• Result: a notification titled "Cancellation requested" reports the count. When some requests fail, the notification "Couldn't cancel every run" names them.

NavigationCopy Anchor Link

SidebarCopy Anchor Link

The sidebar has a search field with the placeholder "Search". It filters views, pin shortcuts and providers by name. From top to bottom the sidebar lists:

1. "Pinned" and the pin shortcuts under it.
2. "All providers" with each provider under it.
3. "All views", a group that collapses. It starts open, stays open while one of its views is active, and remembers its state.
4. The tree of custom and config views, with the pipeline count. A view with sub-views expands.

Right-click on a view opens the same menu as on its tab, with "Move up" and "Move down" in place of "Move left" and "Move right". The rail of the collapsed sidebar lists the views and the providers with tooltips, and has no pin shortcuts.

TabsCopy Anchor Link

The tabs above the table list All, then Pinned and the custom views in their order, then the config views. Each provider has a tab right after the Pinned tab, with a status dot, the name and the count. View tabs show the pipeline count.

• Reorder: drag a tab, or use "Move left" and "Move right". The Pinned tab moves too, and the provider tabs move with it. The order is part of the stored views.
• Manage views: the icon button next to the tabs opens a dialog with the nested list of views. Drag a view to reorder it. Config views are listed under it with the line "From config.toml".
• Context menu: "Edit view…", "New sub-view…", "Pin view", "Move left", "Move right" and "Delete view". A right-click on a provider tab offers "Cancel running…".

iPhoneCopy Anchor Link

The Pipelines tab shows a strip of chips instead of tabs: "All pipelines", one chip per provider with its count and status dot, then the other top-level views. The Pinned page has its own entry in the tab bar. The "More" menu holds Select, Filter, Edit Views, and the sort, grouping and hidden options. Layout and Expand all are not offered. A swipe to the left on a row reveals Pin and Trigger.

Views in config.tomlCopy Anchor Link

A [views.<key>] table defines a read-only view. Pipedash adds it after the other views. The key becomes the id config:<key>.

[views.release]
name = "Release"
providers = ["github-work"]
repositories = ["acme/*"]
statuses = ["failed", "degraded"]
sort = "status"

The rules follow the same logic as the rules of a custom view. The view needs at least one of providers, repositories, name_contains or statuses.

A config view is always at the top level. The UI has no menu to edit, delete, pin or reorder it. The view shows "No pipelines in this view" while no pipeline matches. A link to a config view that no longer exists shows "View not found".

The file reloads on its own. The watcher described on the Configuration page checks it every 5 seconds, and the views update without a restart. Pipedash checks the whole file before it applies anything. A view without a name, with an empty key, without rules or with an invalid pattern rejects the file, and the provider blocks of the same file wait too. At startup, an invalid file opens the "Configuration file has errors" screen. A factory reset removes the provider tables only, so [views.*] stays in the file.

StorageCopy Anchor Link

Custom views, their members, the pins and the hidden pipelines live in the database, in SQLite or PostgreSQL. They move with a storage migration. Removing a provider removes its pipelines from every view and drops it from the rules. A view that loses its only provider keeps existing, with empty rules, so it stays editable.

The web server offers the views on the /pipeline-views routes and sends a pipeline-views-changed event over the WebSocket after every change. The REST API page lists them.