Pinned views

Browse to a scope, filter it, then press P. The result becomes a tab beside the built-in ones, and it is still there on the next run.

pinned-tabs
Each tab is a scope plus a filter. The count comes from the connection itself, so the size is known before the rows arrive.

The three keys

StepKeyWhat happens
1bBrowse to a group or project
2fFilter it down to what you want
3PPin it, with a name prefilled from the scope and the filter

A view is built by browsing, filtering, and pinning rather than by editing a file.

What a pin remembers

  • The scope, meaning the group or project you were standing in, subgroups included.
  • The filter, as typed values rather than a string.
  • The sort order, and how often the view refreshes.
  • Which GitLab instance it came from, once you have more than one.

Managing pins

KeyActionKeyAction
Ppin the current viewh lmove between tabs
Pon a pinned tab, unpin it, with undorrefresh this one

Unpinning always offers an undo, because one key is easy to press twice.

Each view carries its own refresh interval. A "failed today" tab polls every thirty seconds while a "merged this quarter" tab checks hourly. See refresh and caching.

The state file

labdash writes your pins to a state file beside your settings. The application owns that file:

  • labdash writes it, you do not. It has no documented schema.
  • It is written atomically. A crash during a write cannot cost you your pins.
  • It migrates silently. A new version reads a file written by an older one.
  • A corrupt file resets with a note. It never becomes a startup error.

Delete it and you lose your pins. Nothing else changes.