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 "next" 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!

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#668