Should --force allow redeploying a chaos-deployed instance without --chaos? #646

New Issue

2025-09-04T16:07:05Z

3wordchant commented

2025-09-04 16:07:05 +00:00

This integration test fails after !644, implying that the following should work:

abra app deploy foo.bar.com --chaos
abra app deploy foo.bar.com --force

Personally I kinda still stand by #554 comment 26664, "I think bailing on non-chaos deploy is the least-wrong thing to do here"

[This integration test](https://git.coopcloud.tech/toolshed/abra/src/branch/main/tests/integration/app_deploy.bats#L229-L231) fails after !644, implying that the following should work: ```bash abra app deploy foo.bar.com --chaos abra app deploy foo.bar.com --force ``` Personally I kinda still stand by [#554 comment 26664](https://git.coopcloud.tech/toolshed/abra/issues/554#issuecomment-26664), "I think bailing on non-chaos deploy is the least-wrong thing to do here"

3wordchant added the question label 2025-09-04 16:07:05 +00:00

3wordchant commented

2025-09-04 16:11:19 +00:00

Ah and this test implies that abra app deploy foo.bar.com <commit hash> should work without --chaos too 🤔

Ah and [this test](https://git.coopcloud.tech/toolshed/abra/src/branch/main/tests/integration/app_deploy_env_version.bats#L58-L59) implies that `abra app deploy foo.bar.com <commit hash>` should work without `--chaos` too 🤔

decentral1se commented

2025-09-04 17:21:47 +00:00

Oh, great spot.

Personally I kinda still stand by #554 (comment), "I think bailing on non-chaos deploy is the least-wrong thing to do here"

I'm for that as well! Passing -Cf seems more logical to me.

We also had a similar feeling situation with trying to name --latest on abra app deploy and chaining --force --latest seemed quite consistent.

Ah and this test implies that abra app deploy foo.bar.com should work without --chaos too 🤔

Seems a bit tedious but I'm for also mandating -C here just for simplicity / consistency sake.

Oh, great spot. > Personally I kinda still stand by https://git.coopcloud.tech/toolshed/abra/issues/554#issuecomment-26664, "I think bailing on non-chaos deploy is the least-wrong thing to do here" I'm for that as well! Passing `-Cf` seems more logical to me. We also had a similar feeling situation with trying to name `--latest` on `abra app deploy` and chaining `--force --latest` seemed quite consistent. > Ah and this test implies that abra app deploy foo.bar.com <commit hash> should work without --chaos too 🤔 Seems a bit tedious but I'm for also mandating `-C` here just for simplicity / consistency sake.

👍 1

3wordchant commented

2025-09-04 17:52:34 +00:00

OK roger that I'll update the tests 🫡

🎉 1

decentral1se added this to the Abra v0.11.x project 2025-09-04 20:55:57 +00:00

decentral1se moved this to In Progress in Abra v0.11.x on 2025-09-04 20:56:56 +00:00

3wordchant was assigned by decentral1se

2025-09-08 14:46:53 +00:00

3wordchant referenced this issue

2025-09-08 18:52:04 +00:00

`abra app ls -S`: FATA: [hash] is not supported #554

3wordchant commented

2025-09-08 18:53:35 +00:00

Tales from Matrix:

  ✗ hash deploy then force deploy [9387]
  ...
   output : FATA cannot use [version] and --chaos together

after PR !644 now there is no way to deploy a specific hash 😕
well, there is - manually checking out that commit then --chaos. but no single command any more
maybe there's an argument that --chaos shouldn't be required if someone specifies the hash on the CLI?
—3wordchant

fack, maybe we're back to "--chaos implied by deploying commit hash" as a log.Warn and then set internal.Chaos = true when deploying specific hash and run away?
—decentral1se

yeah this sounds fine actually
—3wordchant

Tales from Matrix: ``` ✗ hash deploy then force deploy [9387] ... output : FATA cannot use [version] and --chaos together ``` > after PR !644 now there is no way to deploy a specific hash 😕 > well, there is - manually checking out that commit then `--chaos`. but no single command any more > maybe there's an argument that `--chaos` shouldn't be required if someone specifies the hash on the CLI? > —3wordchant > fack, maybe we're back to "`--chaos` implied by deploying commit hash" as a log.Warn and then set `internal.Chaos = true` when deploying specific hash and run away? > —decentral1se > yeah this sounds fine actually > —3wordchant

3wordchant commented

2025-09-09 02:22:49 +00:00

➜ ./abra app deploy ghost-demo 
WARN version '298401b2' appears to be a chaos commit, but --chaos/-C was not provided
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                  NEW DEPLOY OVERVIEW                  ┃
┃                                                       ┃
┃ DOMAIN                ghost.swarm-test.autonomic.zone ┃
┃ RECIPE                ghost                           ┃
┃ SERVER                swarm-test.autonomic.zone       ┃
┃ CONFIG                compose.yml                     ┃
┃                                                       ┃
┃ CURRENT DEPLOYMENT    N/A                             ┃
┃ ENV VERSION           298401b2                        ┃
┃ NEW DEPLOYMENT        298401b2                        ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
...
➜ ./abra app ls -S -s swarm-test.autonomic.zone
┏━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓
┃  RECIPE   ┃              DOMAIN               ┃          SERVER           ┃  STATUS  ┃  CHAOS  ┃   VERSION    ┃   UPGRADE    ┃ AUTOUPDATE ┃
┣━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━╋━━━━━━━━━╋━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━╋━━━━━━━━━━━━┫
┃ ghost     ┃ ghost.swarm-test.autonomic.zone   ┃ swarm-test.autonomic.zone ┃ deployed ┃ true    ┃ 298401b2     ┃ latest       ┃ false      ┃
...

``` ➜ ./abra app deploy ghost-demo WARN version '298401b2' appears to be a chaos commit, but --chaos/-C was not provided ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ NEW DEPLOY OVERVIEW ┃ ┃ ┃ ┃ DOMAIN ghost.swarm-test.autonomic.zone ┃ ┃ RECIPE ghost ┃ ┃ SERVER swarm-test.autonomic.zone ┃ ┃ CONFIG compose.yml ┃ ┃ ┃ ┃ CURRENT DEPLOYMENT N/A ┃ ┃ ENV VERSION 298401b2 ┃ ┃ NEW DEPLOYMENT 298401b2 ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ... ➜ ./abra app ls -S -s swarm-test.autonomic.zone ┏━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓ ┃ RECIPE ┃ DOMAIN ┃ SERVER ┃ STATUS ┃ CHAOS ┃ VERSION ┃ UPGRADE ┃ AUTOUPDATE ┃ ┣━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━╋━━━━━━━━━╋━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━╋━━━━━━━━━━━━┫ ┃ ghost ┃ ghost.swarm-test.autonomic.zone ┃ swarm-test.autonomic.zone ┃ deployed ┃ true ┃ 298401b2 ┃ latest ┃ false ┃ ... ```

decentral1se commented

2025-09-09 07:43:32 +00:00

@3wordchant oh yeh, great! this seems good? that may be the winner for now then? 🤸 And then no tests chaos to fix? Maybe one to add to ensure that WARN message appears but otherwise, I think we could run away with this fix and then re-close #554 and call it a day.

@3wordchant oh yeh, great! this seems good? that may be the winner for now then? 🤸 And then no tests chaos to fix? Maybe one to add to ensure that `WARN` message appears but otherwise, I think we could run away with this fix and then re-close https://git.coopcloud.tech/toolshed/abra/issues/554 and call it a day.

3wordchant referenced this issue

2025-09-09 19:59:20 +00:00

fix: set "chaos" if a specified* version is "chaos-y" #659

decentral1se closed this issue

2025-09-09 20:24:04 +00:00

decentral1se moved this to Done in Abra v0.11.x on 2025-09-09 20:24:27 +00:00

Sign in to join this conversation.