Un-chaos unhelpful error and fuzzy brain / no git version loss #668

New Issue

decentral1se · 2025-09-16T13:20:34Z

decentral1se commented

2025-09-16 13:20:34 +00:00

You deploy version X, then hack it and deploy --chaos then undeploy and want to deploy the old version X and get:

FATA parsing deployed version failed: version <...commit-sha...> is not supported (matched: ^[a-f0-9]{7,40}$)

Your --chaos deploy put the commit hash in your app .env. You can pass abra app deploy <app> <version-x> to override it. You can also pass abra app deploy --latest (if version X is the latest one!). You can also edit the .env and delete the :<commit-sha> to get it to "reset" (which will then pick the latest version on deploy).

The error doesn't really help you in this case.

Also if you forgot what version X is and don't use Git, you're really in trouble! If you can't do --latest (for whatever reason, some intermediate upgrade will break your deployment), then it is really easy to get lost. I think abra could potentially help here by stashing the last version used when you --chaos so that you can abra app deploy --unchaos? That would recover your version once you're finished with chaos hacking.

Or maybe simpler, abra can record somewhere every version it sees so you can track back somehow? abra app deploy --history could just be a read-only list output with timestamps? This could be stashed in ~/.abra/cache or something, idk. This all seems a bit tricky.

Other work-around is "just use git" but this is not great for new hackers...

These problems are kind of separate but also related.

/cc @iexos @cyrnel @3wordchant @p4u1 (would love your feedback on this)

You deploy version X, then hack it and `deploy --chaos` then undeploy and want to deploy the old version X and get: ``` FATA parsing deployed version failed: version <...commit-sha...> is not supported (matched: ^[a-f0-9]{7,40}$) ``` Your `--chaos` deploy put the commit hash in your app `.env`. You can pass `abra app deploy <app> <version-x>` to override it. You can also pass `abra app deploy --latest` (if version X is the latest one!). You can also edit the `.env` and delete the `:<commit-sha>` to get it to "reset" (which will then pick the latest version on `deploy`). The error doesn't really help you in this case. Also if you forgot what version X is and don't use Git, you're really in trouble! If you can't do `--latest` (for whatever reason, some intermediate upgrade will break your deployment), then it is really easy to get lost. I think `abra` could potentially help here by stashing the last version used when you `--chaos` so that you can `abra app deploy --unchaos`? That would recover your version once you're finished with chaos hacking. Or maybe simpler, `abra` can record somewhere every version it sees so you can track back somehow? `abra app deploy --history` could just be a read-only list output with timestamps? This could be stashed in `~/.abra/cache` or something, idk. This all seems a bit tricky. Other work-around is "just use git" but this is not great for new hackers... These problems are kind of separate but also related. /cc @iexos @cyrnel @3wordchant @p4u1 (would love your feedback on this)

👍 1

decentral1se added the

enhancement

label 2025-09-16 13:39:39 +00:00

decentral1se added this to the Abra v0.12 project 2025-09-16 13:39:51 +00:00

iexos commented

2025-09-16 15:19:56 +00:00

Deploy history would be great of course, but as a quick fix maybe just suggest something else instead? Like

$ abra app deploy my.app.chaos
Cannot re-deploy previous chaos version (`abcdef+U`), did you mean to use `--chaos`?
To go back to a regular release, specify a release tag or use `--latest`

Deploy history would be great of course, but as a quick fix maybe just suggest something else instead? Like ``` $ abra app deploy my.app.chaos Cannot re-deploy previous chaos version (`abcdef+U`), did you mean to use `--chaos`? To go back to a regular release, specify a release tag or use `--latest` ```

👍 1

cyrnel commented

2025-09-17 23:21:12 +00:00

In my case, I had a --chaos deploy because I was testing a new version, then wanting to roll forward to the new version once I released it. So I only checked the flags/docs for abra app upgrade because I was convinced I was doing an upgrade.

I would think deploy should not have anything to do with versioning; it should just deploy whatever version you have configured. Other commands would handle the version (like upgrade and rollback). But that might have negative effects since you don't wanna input SHAs every time you do a new chaos deploy, etc.

In my case, I had a `--chaos` deploy because I was testing a new version, then wanting to roll _forward_ to the new version once I released it. So I only checked the flags/docs for `abra app upgrade` because I was convinced I was doing an upgrade. I would think `deploy` should not have anything to do with versioning; it should just deploy whatever version you have configured. Other commands would handle the version (like `upgrade` and `rollback`). But that might have negative effects since you don't wanna input SHAs every time you do a new chaos deploy, etc.

decentral1se commented

2025-09-18 07:56:27 +00:00

@cyrnel abra app deploy is about the most versatile command with regards to versioning based on what people have needed it to do down through the years. It's the swiss army knife of the entire command-line tool basically. I think the --latest flag works in your case (or passing the version) relatively OK.

#668 (comment) seems like a good / easy to fix for now if someone wants to take a run at it.

Caching a simple read-only list of versions and timestamps per-app in $ABRA_DIR/.cache seems like a good thing to do eventually. This is pending some good CLI UI/UX also. Please anyone take a stab at it if you feel like it!

@cyrnel `abra app deploy` is about the most versatile command with regards to versioning based on what people have needed it to do down through the years. It's the swiss army knife of the entire command-line tool basically. I think the `--latest` flag works in your case (or passing the version) relatively OK. https://git.coopcloud.tech/toolshed/abra/issues/668#issuecomment-27164 seems like a good / easy to fix for now if someone wants to take a run at it. Caching a simple read-only list of versions and timestamps per-app in `$ABRA_DIR/.cache` seems like a good thing to do eventually. This is pending some good CLI UI/UX also. Please anyone take a stab at it if you feel like it!

simon commented

2025-09-24 11:59:32 +00:00

Hi all, thanks for trying to solve this issue!
I also agree with all your proposals so far.

Also had the same experience as cyrnel and would love to see a fix for this, too. In the situation described, I don't care about the currently deployed (chaos) version and just want to override it with my upgrade. Guess a warning would make sense, but I'd like to force the upgrade in this case

Hi all, thanks for trying to solve this issue! I also agree with all your proposals so far. Also had the same experience as cyrnel and would love to see a fix for this, too. In the situation described, I don't care about the currently deployed (chaos) version and just want to override it with my upgrade. Guess a warning would make sense, but I'd like to force the upgrade in this case

iexos commented

2025-09-24 15:15:01 +00:00

Maybe another option that would be nice: if deploy version is not specified and cannot be unambiguously deduced, use a picker menu for choosing a release (starting with latest), like with app upgrade, app new etc

Could also add chaos as an option.

The only downside is that this might fuel an expectation to have this picker every time. But maybe it should, if none of [release tag, --latest, --chaos] is specified? (and pick the last deploy as default choice if known, and mark it as such)

Maybe another option that would be nice: if deploy version is not specified and cannot be unambiguously deduced, use a picker menu for choosing a release (starting with latest), like with `app upgrade`, `app new` etc Could also add `chaos` as an option. The only downside is that this might fuel an expectation to have this picker every time. But maybe it should, if none of `[release tag, --latest, --chaos]` is specified? (and pick the last deploy as default choice if known, and mark it as such)

decentral1se added the

bug

label 2025-09-24 23:04:26 +00:00

decentral1se moved this to Prioritised in Abra v0.12 on 2025-09-29 06:58:01 +00:00

decentral1se started working 2025-09-29 15:28:42 +00:00

decentral1se worked for 1 hour

2025-09-29 16:29:28 +00:00

decentral1se referenced this issue from a commit

2025-09-29 17:46:44 +00:00

fix: dont overwrite label when chaos

decentral1se referenced this issue from a commit

2025-09-29 17:46:44 +00:00