Flatten dashboard persistence directory layout - #20006
Flatten dashboard persistence directory layout#20006James Newton-King (JamesNK) wants to merge 2 commits into
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 20006Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 20006" |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
🟡 Changes recommended
Critical storage collisions and migration gaps must be resolved before approval.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Flattens dashboard persistence into shared runs and resumes directories while preserving application identification.
Changes:
- Adds application marker files for run discovery.
- Relocates resume databases and locks.
- Renames the working-directory property and updates tests.
File summaries
| File | Description |
|---|---|
tests/Aspire.Dashboard.Tests/Model/DashboardDataSourceTests.cs |
Updates persistence and discovery tests. |
tests/Aspire.Dashboard.Tests/Integration/StartupTests.cs |
Adjusts failed-startup cleanup coverage. |
src/Aspire.Dashboard/ServiceClient/DashboardRunStore.cs |
Implements the flattened layout. Outstanding issues include run-ID collisions, missing run/resume migration compatibility, and outdated persistence documentation. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 4
- Review effort level: Balanced
Tests selector9 / 99 PR test projects · 3 PR jobs · 1 advisory-only target, from 3 changed files. Selected PR test projects (9 / 99)
Selected PR jobs (3)
Advisory workflow impact (1)
How these were chosen — grouped by what changed🔧 📦 affected project 🧪 🧪 Job reasons
Selection computed for commit |
There was a problem hiding this comment.
🟡 Changes recommended
Constructor failure cleanup must prevent orphaned run directories, and the security documentation must be made consistent.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
Suppressed comments (1)
docs/specs/dashboard-persistence.md:95
- This new permission/layout contract contradicts the unchanged Security and privacy section below: line 330 still says data is under
<ASPIRE_HOME>/dashboard/<application-directory>, and line 332 says the Dashboard does not set Unix file modes. Update that section to describe the sharedruns/resumespaths and clarify which directories are repaired to0700versus which root/file permissions remain the operator's responsibility.
On Unix, the shared `runs` and `resumes` directories are created with owner-only (`0700`) permissions. Resume application directories are also restricted to that mode before persistent data is accessed. Existing directories are repaired to that mode. On Windows, directories are created without Unix permission flags and use inherited ACLs.
- Files reviewed: 4/4 changed files
- Comments generated: 1
- Review effort level: Balanced
| File.WriteAllText(Path.Combine(CurrentWorkingDirectory, _applicationMarkerFileName), string.Empty); | ||
| _runLock = runLock; | ||
| } | ||
| catch | ||
| { | ||
| runLock.Dispose(); | ||
| throw; |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
Description
Dashboard persistence currently nests historical runs under an application-specific directory. This makes the storage hierarchy harder to inspect and prevents all run snapshots from sharing one predictable location.
This change:
runsdirectory.run.json.resumesdirectory.CurrentWorkingDirectory.User-facing usage
No configuration changes are required. With a configured dashboard data directory, persisted data now has this shape:
Security considerations
Persisted dashboard data can contain telemetry, environment variables, and console logs. The shared
runsandresumesdirectories and resume application directories are restricted to owner-only permissions (0700) on Unix. Windows uses inherited ACLs. Temporary mode usesDirectory.CreateTempSubdirectory, which creates an owner-only directory on Unix and inherits the current user's temporary-directory ACL on Windows.Validation:
The focused failed-startup cleanup test also passed with the shared runs directory.
Fixes # (issue)
Checklist
<remarks />and<code />elements on your triple slash comments?