fix: chaos handling fixes #674

decentral1se · 2025-09-29T17:57:09Z

decentral1se commented

2025-09-29 17:57:09 +00:00

Started down the rabbit hole that is #668. Unsurprisingly there was a bug (3696d63a34) in how we display the chaos version in nearly every overview and fixing this caused the house of cards to fall down (the rest of the commits) 😆. The TLDR; is that we actually were overwriting the standard version label (e.g. coop-cloud.RECIPE_MY_APP.version) with the chaos version which was causing abra to choke. Even if we have a chaos version (commit SHA or unstaged (+U)), we know the stable version because it is in the compose configuration in parallel. When we preserve this in the label we can always then feed this to upgrade/rollback, resolving the main use-case blocker in #668.

You can once more do the following without running into an error:

abra app deploy 1312.net
... make unstaged changes in the recipe...
abra app deploy 1312.net --chaos
abra app upgrade 1312.net

The only remaining abra explosion is when you undeploy a chaos version with unstaged changes, reset the changes and try to deploy it again. The improved error message described in #668 (comment) is now provided. The deploy overviews will also show the chaos version more consistently. Thanks to #657 we now see a lot more of what is changing. I think I even managed to fix #557 also 🙃

Started down the rabbit hole that is https://git.coopcloud.tech/toolshed/abra/issues/668. Unsurprisingly there was a bug (https://git.coopcloud.tech/toolshed/abra/commit/3696d63a34734e05836ef31f14e3d7e9cdbcf18e) in how we display the chaos version in nearly every overview and fixing this caused the house of cards to fall down (the rest of the commits) 😆. The TLDR; is that we actually were overwriting the standard version label (e.g. `coop-cloud.RECIPE_MY_APP.version`) with the chaos version which was causing `abra` to choke. Even if we have a chaos version (commit SHA or unstaged (**+U**)), we know the stable version because it is in the compose configuration in parallel. When we preserve this in the label we can always then feed this to `upgrade`/`rollback`, resolving the main use-case blocker in https://git.coopcloud.tech/toolshed/abra/issues/668. You can once more do the following without running into an error: 1. `abra app deploy 1312.net` 1. `... make unstaged changes in the recipe...` 1. `abra app deploy 1312.net --chaos` 1. `abra app upgrade 1312.net` The only remaining `abra` explosion is when you undeploy a chaos version with unstaged changes, reset the changes and try to deploy it again. The improved error message described in https://git.coopcloud.tech/toolshed/abra/issues/668#issuecomment-27164 is now provided. The deploy overviews will also show the chaos version more consistently. Thanks to https://git.coopcloud.tech/toolshed/abra/pulls/657 we now see a lot more of what is changing. I think I even managed to fix https://git.coopcloud.tech/toolshed/abra/issues/557 also 🙃

🎉 2

decentral1se added 10 commits 2025-09-29 17:57:09 +00:00

fix: dont overwrite label when chaos 3696d63a34