fix(cli): refresh setup before hosted updates - #533
Conversation
Greptile SummaryThis PR embeds setup revisions in generated deployment CLIs and adds one-time setup reconciliation before hosted updates. It also expands setup-lock acquisition and direct setup preparation to running and retryable failed states.
Confidence Score: 3/5The PR should not merge until running deployments can resolve their current release for setup refreshes and successful setup handoffs persist the applied revision. The new refresh path fails for its primary running-deployment case because completed deployments no longer have a desired release, and even a setup run that reaches the normal Provisioning handoff skips the revision marker and will be repeated later. Files Needing Attention: crates/alien-deploy-cli/src/commands/up.rs
|
| Filename | Overview |
|---|---|
| crates/alien-deploy-cli/src/commands/up.rs | Adds hosted setup refresh orchestration, but running deployments lack the desired release it requires and normal Neutral handoffs do not persist the applied revision. |
| crates/alien-deployment/src/manager_api_transport.rs | Expands setup-run lock eligibility to the lifecycle states used by the new refresh flow. |
| crates/alien-core/src/deployment/state.rs | Adds backward-compatible persisted metadata for the last applied direct setup revision. |
| crates/alien-core/src/embedded_config.rs | Adds an optional, backward-compatible setup revision to embedded deployment CLI configuration. |
Sequence Diagram
sequenceDiagram
participant CLI as Generated deployment CLI
participant Manager
participant Runner as Setup runner
CLI->>Manager: Read deployment and applied setup revision
alt Packaged revision differs
CLI->>Manager: Acquire setup-run lock
CLI->>Manager: Read desired/current release
CLI->>Runner: Prepare and run direct setup
Runner-->>CLI: Provisioning handoff (Neutral)
CLI->>Manager: Reconcile state with applied revision
CLI->>Manager: Release lock
end
Prompt To Fix All With AI
### Issue 1
crates/alien-deploy-cli/src/commands/up.rs:4153-4155
**Running refresh lacks target release**
When a newer generated CLI refreshes a running or refresh-failed hosted deployment, `push_initial_setup` reconstructs `target_release` only from the cleared `desired_release_id`, causing the command to fail with “A setup update requires a desired release” instead of refreshing setup from the current release.
### Issue 2
crates/alien-deploy-cli/src/commands/up.rs:4220-4225
**Handoff skips revision persistence**
When setup reaches its normal Provisioning handoff, the runner returns `LoopOutcome::Neutral`, but this block records `direct_setup_revision` only for `Success`; the revision therefore remains unset and later invocations rerun setup-owned infrastructure for the same package revision.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "fix(cli): refresh setup before hosted up..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| DeploymentStatus::Running | ||
| | DeploymentStatus::UpdateFailed | ||
| | DeploymentStatus::RefreshFailed |
There was a problem hiding this comment.
When a newer generated CLI refreshes a running or refresh-failed hosted deployment, push_initial_setup reconstructs target_release only from the cleared desired_release_id, causing the command to fail with “A setup update requires a desired release” instead of refreshing setup from the current release.
Knowledge Base Used:
Prompt To Fix With AI
This is a comment left during a code review.
Path: crates/alien-deploy-cli/src/commands/up.rs
Line: 4153-4155
Comment:
**Running refresh lacks target release**
When a newer generated CLI refreshes a running or refresh-failed hosted deployment, `push_initial_setup` reconstructs `target_release` only from the cleared `desired_release_id`, causing the command to fail with “A setup update requires a desired release” instead of refreshing setup from the current release.
**Knowledge Base Used:**
- [CLI and deployment workflows](https://app.greptile.com/alien/-/custom-context/knowledge-base/alienplatform/alien/-/docs/cli-and-deployment.md)
- [Deployment and packaging](https://app.greptile.com/alien/-/custom-context/knowledge-base/alienplatform/alien/-/docs/deployment-and-packaging.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
| if let Ok(result) = &runner_result { | ||
| if matches!(result.loop_result.outcome, LoopOutcome::Success) { | ||
| if let (Some(revision), Some(metadata)) = | ||
| (setup_revision, state.runtime_metadata.as_mut()) | ||
| { | ||
| metadata.direct_setup_revision = Some(revision.to_string()); |
There was a problem hiding this comment.
When setup reaches its normal Provisioning handoff, the runner returns LoopOutcome::Neutral, but this block records direct_setup_revision only for Success; the revision therefore remains unset and later invocations rerun setup-owned infrastructure for the same package revision.
Knowledge Base Used:
Prompt To Fix With AI
This is a comment left during a code review.
Path: crates/alien-deploy-cli/src/commands/up.rs
Line: 4220-4225
Comment:
**Handoff skips revision persistence**
When setup reaches its normal Provisioning handoff, the runner returns `LoopOutcome::Neutral`, but this block records `direct_setup_revision` only for `Success`; the revision therefore remains unset and later invocations rerun setup-owned infrastructure for the same package revision.
**Knowledge Base Used:**
- [CLI and deployment workflows](https://app.greptile.com/alien/-/custom-context/knowledge-base/alienplatform/alien/-/docs/cli-and-deployment.md)
- [Deployment and packaging](https://app.greptile.com/alien/-/custom-context/knowledge-base/alienplatform/alien/-/docs/deployment-and-packaging.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.1 participant
Summary
Testing