Unable to perform ps or undeploy with locally unstaged changes #628

New Issue

simon · 2024-07-23T08:23:48Z

simon commented

2024-07-23 08:23:48 +00:00

Unlike before the latest changes, I'm no more able to execute the abra app ps or abra app undeploy commands with unstaged changes as they fail now and no chaos flag exists.

Previously, my usual dev workflow was like

Edit the recipe
(sometimes) Undeploy dev instance
Redeploy dev instance with --chaos flag
Run abra app ps <domain>
See if everything works
Make a commit

With the changes, steps 2 and 4 aren't working anymore as I have to (at least locally) commit my changes before.

I'm currently working on this branch: https://git.coopcloud.tech/coop-cloud/vikunja/src/branch/merge-frontend-and-api

Undeploy:

abra app un -d todo.dev.local-it.cloud
 DEBUG  <app/app.go:284> collecting metadata from 15 servers: ....
[...]
 DEBUG  <internal/validate.go:98> validated todo.dev.local-it.cloud as app argument
 DEBUG  <git/read.go:123> no /home/sth/.gitignore exists, skipping reading gitignore paths
 DEBUG  <git/read.go:43> discovered git status in /home/sth/.abra/recipes/vikunja:  M compose.yml

 FATAL  <app/undeploy.go:86> vikunja (/home/sth/.abra/recipes/vikunja) has locally unstaged changes? please commit/remove your changes before proceeding

Unlike before the latest changes, I'm no more able to execute the `abra app ps` or `abra app undeploy` commands with unstaged changes as they fail now and no chaos flag exists. Previously, my usual dev workflow was like 1. Edit the recipe 2. (sometimes) Undeploy dev instance 3. Redeploy dev instance with --chaos flag 4. Run `abra app ps <domain>` 5. See if everything works 6. Make a commit With the changes, steps 2 and 4 aren't working anymore as I have to (at least locally) commit my changes before. I'm currently working on this branch: https://git.coopcloud.tech/coop-cloud/vikunja/src/branch/merge-frontend-and-api ### Undeploy: ``` abra app un -d todo.dev.local-it.cloud DEBUG <app/app.go:284> collecting metadata from 15 servers: .... [...] DEBUG <internal/validate.go:98> validated todo.dev.local-it.cloud as app argument DEBUG <git/read.go:123> no /home/sth/.gitignore exists, skipping reading gitignore paths DEBUG <git/read.go:43> discovered git status in /home/sth/.abra/recipes/vikunja: M compose.yml FATAL <app/undeploy.go:86> vikunja (/home/sth/.abra/recipes/vikunja) has locally unstaged changes? please commit/remove your changes before proceeding ```

👀 1

simon added the

bug

label 2024-07-23 08:23:48 +00:00

simon referenced this issue

2024-07-23 08:34:03 +00:00

`abra app ps` checks out wrong version #629

decentral1se added the

abra

label 2024-07-23 08:38:41 +00:00

decentral1se commented

2024-07-23 09:24:49 +00:00

OK returning from the rabbit hole of design, workflows, philosophical questions and the meaning of chaos with @simon, we have a plan 🎉

undeploy: it sends a request to the runtime with only the stack name of the app, so we don't need to touch the checkout at all. so that's simple, we return this behaviour to what it was before
ps: it does actually require the recipe compose configurations to list the services and then from there, query each service status. this would mean adding a --chaos/-C flag to ps to be consistent. however, we decided that maybe this isn't the ideal implementation because we want to "get as close to the actual runtime information as possible". so, we agreed that it would be nice if ps would first query the actual live deployment to get the services and from there, query their status.

annnd integration tests coming then to avoid regressions on these ✅

OK returning from the rabbit hole of design, workflows, philosophical questions and the meaning of chaos with @simon, we have a plan 🎉 * `undeploy`: it sends a request to the runtime with only the stack name of the app, so we don't need to touch the checkout at all. so that's simple, we return this behaviour to what it was before * `ps`: it does actually require the recipe compose configurations to list the services and then from there, query each service status. this would mean adding a `--chaos/-C` flag to `ps` to be consistent. however, we decided that maybe this isn't the ideal implementation because we want to "get as close to the actual runtime information as possible". so, we agreed that it would be nice if `ps` would first query the actual live deployment to get the services and from there, query their status. annnd integration tests coming then to avoid regressions on these ✅

👍 1

decentral1se referenced this issue

2024-07-23 09:25:21 +00:00

`abra app ps` checks out wrong version #629

simon commented

2024-07-24 08:03:10 +00:00

For the sake of completeness, @moritz pointed out that we want to be able to verify whether all containers supposed to be deployed were successfully deployed. So it needs more or less a complete diff of what is actually running vs what should be running and we do need the repo status.

So we agreed upon readding the -C flag to abra app ps

For the sake of completeness, @moritz pointed out that we want to be able to verify whether all containers supposed to be deployed were successfully deployed. So it needs more or less a complete diff of what is actually running vs what should be running and we *do* need the repo status. So we agreed upon readding the `-C` flag to `abra app ps`

👍 1

decentral1se referenced this issue from a commit

2024-07-24 14:09:36 +00:00

fix: --chaos/--offline for `abra app ps`

decentral1se referenced this issue from a commit

2024-07-24 14:09:36 +00:00

fix: dont checkout version for `abra app undeploy`

decentral1se referenced this issue from toolshed/abra

2024-07-24 14:10:31 +00:00

fix: ps/undeploy and WriteRecipeVersion #444

~~decentral1se referenced this issue 2024-07-24 19:48:02 +00:00~~

`abra` v0.10.x-beta release planning #583