Chaos deploy written to .env overrides stable deploy #662

Closed
opened 2024-12-30 17:39:17 +00:00 by decentral1se · 0 comments
Owner

It's a brave new world.

  • hack on recipe
  • abra app deploy foo.com -C
  • <hash>+U gets written to foo.com.env
  • wipe changes on recipe
  • abra app deploy foo.com
  • run into #651 (ignore for now, manually remove +U from the foo.com.env 😅)
  • see the deploy overview

Firstly, it shouldn't deploy without --force/--chaos 🙈

Secondly, the deploy overview shows:

  • "current chaos": <hash>+U (correct)
  • "new chaos": <hash> (wrong)

In this case, I'm deploying the latest release tag (automatically chosen when running app app deploy). However, because <hash> is in the foo.com.env, the logic overrides and assumes a chaos deploy.

In this case, we should not override unless we pass --chaos again.

It's a brave new world. * hack on recipe * `abra app deploy foo.com -C` * `<hash>+U` gets written to `foo.com.env` * wipe changes on recipe * `abra app deploy foo.com` * ~~run into https://git.coopcloud.tech/toolshed/organising/issues/651 (ignore for now, manually remove `+U` from the `foo.com.env` 😅)~~ * see the deploy overview Firstly, it shouldn't deploy without `--force/--chaos` 🙈 Secondly, the deploy overview shows: * "current chaos": `<hash>+U` (correct) * "new chaos": `<hash>` (wrong) In this case, I'm deploying the latest release tag (automatically chosen when running `app app deploy`). However, because `<hash>` is in the `foo.com.env`, the logic overrides and assumes a chaos deploy. In this case, we should not override unless we pass `--chaos` again.
decentral1se added the
bug
abra
labels 2024-12-30 17:39:17 +00:00
Sign in to join this conversation.
No description provided.