Conversation
Deployment is the core Miren workflow but had no dedicated docs page. Add one as the first item under Features, covering the full lifecycle: deploying, build detection, deploy-time env vars, redeploying existing versions, rollback, history, cancellation, and git provenance.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughAdds a new documentation page 📝 Coding Plan
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/docs/deployment.md`:
- Around line 128-134: The status filter docs are inconsistent with the server
validation (servers/deployment/server.go) which accepts six values; update the
filter description near the "Status filter" section (around the current
three-value list) to either enumerate all six supported statuses with their
icons — active (✓), succeeded (✓), failed (✗), rolled_back (↩), in progress (⟳),
cancelled (⊘) — or explicitly state that only a subset is exposed and which
ones; ensure the language matches the legend above and mentions the exact status
tokens (active, succeeded, failed, rolled_back, in progress, cancelled) so the
docs align with the server validation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0675d40c-5e84-4637-9408-769eba7d8fa5
📒 Files selected for processing (2)
docs/docs/deployment.mddocs/sidebars.ts
| Status icons: | ||
| - **✓** — active (currently running) or succeeded | ||
| - **✗** — failed | ||
| - **↩** — rolled back | ||
| - **⟳** — in progress | ||
| - **⊘** — cancelled | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify which status values are actually accepted by `miren app history --status`
# Expected: find enum/validation/help text that defines canonical allowed values.
rg -nP -C3 --glob '!docs/**' -- '--status|rolled_back|succeeded|in_progress|cancelled|active|failed'Repository: mirendev/runtime
Length of output: 50374
🏁 Script executed:
cd docs/docs && cat -n deployment.md | sed -n '125,145p'Repository: mirendev/runtime
Length of output: 890
🏁 Script executed:
# Search for the CLI implementation of the status filter in the app history command
# Look for status enum/validation definitions
rg -n 'app.*history|history.*status' --glob '!docs/**' -t go | head -20Repository: mirendev/runtime
Length of output: 717
🏁 Script executed:
# Search more broadly for status-related constants or enums
rg -n 'active|rolled_back|in_progress|succeeded' --glob '!docs/**' -t go | grep -i 'const\|enum\|status' | head -30Repository: mirendev/runtime
Length of output: 2701
🏁 Script executed:
# Find the AppHistory command implementation
rg -n 'AppHistory|func.*History' cli/commands/app_*.go -A 20 | head -50Repository: mirendev/runtime
Length of output: 3659
🏁 Script executed:
# Look for status validation or filter implementation in the app history command
find cli -name '*.go' -exec grep -l 'app.*history\|history.*status' {} \;Repository: mirendev/runtime
Length of output: 142
🏁 Script executed:
# Check the app_status.go file more thoroughly for status filter handling
cat -n cli/commands/app_status.go | head -100Repository: mirendev/runtime
Length of output: 3948
🏁 Script executed:
# Search for deployment status enum/constants
find . -name '*.go' -path '*/deployment*' ! -path './docs/**' | xargs grep -l 'status.*active\|status.*failed\|rolled_back' | head -10Repository: mirendev/runtime
Length of output: 126
🏁 Script executed:
# Look for deployment status type definitions
rg -n 'type.*Status|const.*Status' --glob '!docs/**' -t go | grep -i deploy | head -20Repository: mirendev/runtime
Length of output: 1000
🏁 Script executed:
# Check proto definitions for deployment status
find . -name '*.proto' | xargs grep -l 'deployment\|status' 2>/dev/null | head -5Repository: mirendev/runtime
Length of output: 42
🏁 Script executed:
# Check the deployment server for status handling and validation
rg -n 'active|failed|rolled_back|succeeded|in_progress|cancelled' servers/deployment/server.go -C 2 | head -80Repository: mirendev/runtime
Length of output: 2891
🏁 Script executed:
# Look at the test file to see which statuses are tested
rg -n '"active"|"failed"|"rolled_back"|"succeeded"|"in_progress"|"cancelled"' servers/deployment/server_test.go | head -30Repository: mirendev/runtime
Length of output: 1528
🏁 Script executed:
# Search for status string literals in deployment code more carefully
rg -n 'Status.*=.*"' servers/deployment/ --glob '*.go' | grep -E '(active|failed|succeeded|rolled_back|in_progress|cancelled)'Repository: mirendev/runtime
Length of output: 1823
🏁 Script executed:
# Check how status filter is used in ListDeployments
rg -n 'ListDeployments|listDeploymentsInternal' servers/deployment/server.go -A 10 | head -60Repository: mirendev/runtime
Length of output: 2096
🏁 Script executed:
# Look for where the status filter parameter is validated or used
rg -n 'args\.Status|status filter' servers/deployment/server.go -B 2 -A 5Repository: mirendev/runtime
Length of output: 645
🏁 Script executed:
# Check if the CLI does any validation on the status flag before sending to server
rg -n 'opts\.Status|status.*validation\|status.*check' cli/commands/app_history.go -B 3 -A 5Repository: mirendev/runtime
Length of output: 580
Status filter documentation is incomplete and may mislead users.
The legend (lines 128-133) lists six status values: active, succeeded, failed, rolled_back, in progress, and cancelled. However, the filter documentation (line 141) describes only three: active, failed, rolled_back. The server accepts all six values (verified in servers/deployment/server.go validation). Update the filter description to either list all six supported values or explicitly document that only a subset is intentionally exposed.
Also applies to: 141-143
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/docs/deployment.md` around lines 128 - 134, The status filter docs are
inconsistent with the server validation (servers/deployment/server.go) which
accepts six values; update the filter description near the "Status filter"
section (around the current three-value list) to either enumerate all six
supported statuses with their icons — active (✓), succeeded (✓), failed (✗),
rolled_back (↩), in progress (⟳), cancelled (⊘) — or explicitly state that only
a subset is exposed and which ones; ensure the language matches the legend above
and mentions the exact status tokens (active, succeeded, failed, rolled_back, in
progress, cancelled) so the docs align with the server validation.
The flags table for `miren app history` was already drifting from the actual CLI (CodeRabbit caught a missing status value). Link out to the generated reference page instead of maintaining a copy.
evanphx
left a comment
evanphx
left a comment
There was a problem hiding this comment.
Minor confusion, otherwise looks great!
Evan pointed out that redeploying an existing version doesn't pick up env var changes — it redeploys the old version as-is. Replaced with a more accurate description.
2 participants
Deployment is the core thing Miren does, but we didn't have a dedicated docs page for it. This came up while writing the changelog — we wanted to link "first-class rollbacks" somewhere and realized there was nothing to link to.
This adds a Deployment page as the first item under Features, covering the full deploy lifecycle: how
miren deployworks (upload → server-side detection → build → activate), build detection and--analyze, deploy-time env vars,--versionredeploys,miren rollback,miren app history, cancellation, and git provenance tracking.We went through a few rounds of trimming to keep it focused on what users actually need — implementation details like deployment phases, upload caching internals, and the entity system are left out in favor of the user-facing workflow.
Closes MIR-725