menzeljandClaude Opus 5
d7c4f06e67
A flat volume list is sorted by name, and because Docker names a compose volume <project>_<name> that already puts a stack's volumes next to each other. What it does not do is say so: you read prefixes down the column to work out where one stack's volumes end and the next begins, and `arr-stack_config`, `arr-stack_downloads`, `immich_model-cache` is exactly as hard to scan as it looks. So the stack becomes a heading instead of a prefix repeated on every row. Each group carries the stack's icon and name, its volume count, how many are unused, and — once sizes have been computed — what the stack costs on disk, which is the number you actually want when you are deciding what to clear out. The rows below drop the prefix and show the part that differs: `pgdata`, not `immich_pgdata`. The full name stays in the row's title attribute, since that is what you need when typing a docker command. Ordering: stacks by the name the user gave them rather than by the slug (an id of "zz-project" for a stack called "Alpha" should sort under A), and volumes belonging to no stack appended last, never sorted in — they are the ones you scroll past rather than look for. The case that turned out to be worth building for is the third one. A volume keeps its compose label after the stack is gone, so it is neither owned nor loose. Putting it in the unassigned group would hide it among portainer_data and friends; instead it keeps its own heading, marked "stack removed". A flat list made that invisible, and it is precisely where forgotten data sits. No server change: the owning stack has been on every volume all along, from the com.docker.compose.project label. The grouping is a pure function in lib/ rather than logic inside the page, so the ordering rules are tested directly — ten cases, including the deleted-stack group and that the unassigned group stays last when the only real stack sorts after it. The row markup moved into its own component on the way past. Nesting it one level deeper inside the group left its indentation two stops adrift, and a 70- line <tr> inline in a double map was already the least readable thing in the file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4 lines
89 B
Python
4 lines
89 B
Python
"""Single source of truth for the StackPilot release version."""
|
|
|
|
APP_VERSION = "0.54.0"
|