fix: clear old deployments by id, not appName folder - #5031
Open
brennanneoh wants to merge 5 commits into
Open
Conversation
Old code rm -rf'd a logs folder keyed on appName/serverId, which broke when appName didn't match the actual deployment records. Now looks up deployments by applicationId/composeId and removes all but the most recent successful one via removeDeployment.
No existing coverage for the appName->id refactor. Verifies the most recent successful deployment is kept, older ones deleted, and the newest-only fallback when nothing succeeded.
Kept-vs-delete logic only anchored on the newest "done" deployment, so a build actively running when the user clicked Clear Deployments could get its DB row and log file deleted mid-build. Exclude "running" deployments from the deletion candidates entirely.
…ments - Wrap each removeDeployment call in try/catch (matching removeLastTenDeployments' pattern) so one bad row doesn't abort cleanup of the rest. - Query deployments directly instead of via getDeploymentsByType, which eager-loads a rollback relation clearOldDeployments never uses.
dosubot
Bot
added
the
size:M
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Greptile flagged two issues in clearOldDeployments: - removeDeployment() alone leaves a deleted deployment's rollback Docker image orphaned (cascade only drops the DB row). Call removeRollbackById() first, mirroring removeLastTenDeployments. - deployment.serverId is rarely populated on the row itself (only buildServerId is set at creation time), so removeDeployment's host check silently no-ops for logs that actually live on a remote server. Resolve the real host once via the owning application/compose and batch the remote rm through it, same pattern already used by removeLastTenDeployments.
| if (logPath && logPath !== ".") { | ||
| command += `rm -rf ${logPath};`; | ||
| } | ||
| await removeDeployment(deployment.deploymentId); |
Contributor
There was a problem hiding this comment.
When the final remote deletion command fails because the host or SSH connection is unavailable, this call has already deleted each deployment row, causing the remote log files to remain without the durable logPath metadata needed by a subsequent cleanup attempt.
Knowledge Base Used: Application Deployment Flow
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is this PR about?
clearOldDeployments(backing the "Clear deployments" button on Applications/Compose) used torm -rfa log folder keyed onappName/serverId, but never touched thedeploymentDB rows — so the UI's promise of "keeping only the active deployment (the most recent successful one)" didn't match reality: all logs vanished but every old deployment record stayed.This PR reworks it to look deployments up by
applicationId/composeId, keep the most recent successful (status: "done") deployment (falling back to the newest if none succeeded), and remove the rest via the existingremoveDeploymenthelper (deletes the DB row + its log file). It also:status: "running", so clicking "Clear deployments" mid-build can no longer delete the active deployment's row/log out from under it.removeLastTenDeploymentspattern) so one bad row doesn't abort cleanup of the rest.rollbackeager-join that the sharedgetDeploymentsByTypehelper pulled in for every call.Checklist
canarybranch.Issues related (if applicable)
N/A
Screenshots (if applicable)
N/A — backend-only behavior fix, covered by new unit tests in
apps/dokploy/__test__/deploy/clear-old-deployments.test.ts(6 cases: keep-most-recent-success, fallback-to-newest, single-deployment no-op, never-delete-running, delete-others-while-running, and per-item failure isolation). Full vitest suite: 762/762 passing (excluding a pre-existing, environment-dependent real-exec test unrelated to this change).Greptile Summary
The PR changes deployment-history cleanup to select records by application or compose ID, retain the latest successful deployment, and preserve running deployments.
Confidence Score: 4/5
The PR is not yet safe to merge because a failed remote log-removal command permanently orphans files after their deployment metadata has already been deleted.
Remote cleanup removes each deployment row before executing the accumulated command on the owning server, so a remote execution failure destroys the only durable log-path mapping needed to retry cleanup.
Files Needing Attention: packages/server/src/services/deployment.ts
Reviews (2): Last reviewed commit: "fix: clean up rollback images and use co..." | Re-trigger Greptile
Context used: