-
Notifications
You must be signed in to change notification settings - Fork 7
[CLI] Add a destroy app command #129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
lucarin91
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also add an endpoint for doing this (maybe in a subsequent PR)
|
274a600 to
ef16820
Compare
| return &AppStatusInfo{ | ||
| AppPath: paths.New(pathLabel), | ||
| Status: StatusUninitialized, | ||
| }, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure that this is a valid app? Maybe we still need to return nil nil here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is possible to have a valid app without containers. But, to be sure we also need to perform an app validation within the filesystem or something like that. So for now, it is better to keep the nil nil and maybe handle this use case in a different PR if we decide it is needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I guess it would be better to move the whole part about introducing a new 'uninitialized' app status(valid app with no containers) to a dedicated PR, and focus this one just on implementing the destroy command.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I would keep it, maybe we can add this check to be sure we always return the status of an existing app
diff --git a/internal/orchestrator/helpers.go b/internal/orchestrator/helpers.go
index 3c1564e..b762418 100644
--- a/internal/orchestrator/helpers.go
+++ b/internal/orchestrator/helpers.go
@@ -150,10 +150,14 @@ func getAppStatusByPath(
return nil, fmt.Errorf("failed to list containers: %w", err)
}
if len(containers) == 0 {
- return &AppStatusInfo{
- AppPath: paths.New(pathLabel),
- Status: StatusUninitialized,
- }, nil
+ path := paths.New(pathLabel)
+ if _, err := app.Load(path); err == nil {
+ return &AppStatusInfo{
+ AppPath: path,
+ Status: StatusUninitialized,
+ }, nil
+ }
+ return nil, nil
}
app := parseAppStatus(containers)
Motivation
closes #105
We could add a new app destroycommand (or a similar name) for stopping and removing all the data of an app.
In particular, we should do a docker-compose down and remove the .cache.
We should also consider adding a destroyed (or a better name) that is the default state of an app if it has not been run yet.
With this additional state, we would then be able to always return a state when listing the apps (right now apps and examples that have not been run, will show up as with no state).
Change description
Additional Notes
Reviewer checklist
main.