toolshed/abra
4
2
Fork 18
Code Issues 20 Pull Requests Packages Releases 41 Activity

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

New Issue
Closed
opened 2025-05-10 02:04:11 +00:00 by marlon · 15 comments
marlon commented 2025-05-10 02:04:11 +00:00
Copy Link

I recently undeployed an app which I had running a non-tagged version of the recipe (originally deployed using the --chaos argument). I then re-deployed using the current latest tag. i.e.:

> abra app undeploy baserow.domain.org
> abra app deploy baserow.domain.org

It deployed correctly but afterward, I get this error when running:

> abra app ls -S
DEBU <recipe/git.go:365> detected 0.1.0+1.21.2, 0.1.1+1.21.2, 0.1.2+1.21.2, 0.2.0+1.21.2, 0.3.0+1.25.2, 0.3.1+1.25.2, 0.4.0+1.28.0, 0.5.0+1.29.0, 0.6.0+1.30.1, 0.7.0+1.31.1, 1.0.0+1.31.1 as tags for recipe baserow
FATA <app/list.go:157> 'a8ae8285' is not supported (^[a-f0-9]{7,40}$)
I recently undeployed an app which I had running a non-tagged version of the recipe (originally deployed using the --chaos argument). I then re-deployed using the current latest tag. i.e.: ``` > abra app undeploy baserow.domain.org > abra app deploy baserow.domain.org ``` It deployed correctly but afterward, I get this error when running: ``` > abra app ls -S DEBU <recipe/git.go:365> detected 0.1.0+1.21.2, 0.1.1+1.21.2, 0.1.2+1.21.2, 0.2.0+1.21.2, 0.3.0+1.25.2, 0.3.1+1.25.2, 0.4.0+1.28.0, 0.5.0+1.29.0, 0.6.0+1.30.1, 0.7.0+1.31.1, 1.0.0+1.31.1 as tags for recipe baserow FATA <app/list.go:157> 'a8ae8285' is not supported (^[a-f0-9]{7,40}$) ```
marlon commented 2025-05-10 18:39:10 +00:00
Author
Copy Link

abra version 0.10.1-beta-2fbef41

abra version 0.10.1-beta-2fbef41
decentral1se added the
bug
 label 2025-05-11 08:24:26 +00:00
decentral1se added this to the Abra v0.11.x project 2025-05-11 08:24:34 +00:00
decentral1se moved this to In Progress in Abra v0.11.x on 2025-05-11 08:24:48 +00:00
decentral1se moved this to Backlog in Abra v0.11.x on 2025-05-11 08:24:52 +00:00
decentral1se commented 2025-05-11 08:32:34 +00:00
Owner
Copy Link

Hmmm, seems related: #549

I'm not exactly sure what is going on here. It seems like the deployed version didn't get its coop-cloud.${STACK_NAME}.version=... updated on the abra app deploy? That seems strange. I think I have an idea for a fix but I'm not sure on the exact issue that led to this problem...

@marlon is the app still deployed? Can you send output from abra app labels baserow.domain.org?

Hmmm, seems related: https://git.coopcloud.tech/toolshed/abra/pulls/549 I'm not exactly sure what is going on here. It seems like the deployed version didn't get its `coop-cloud.${STACK_NAME}.version=...` updated on the `abra app deploy`? That seems strange. I think I have an idea for a fix but I'm not sure on the exact issue that led to this problem... @marlon is the app still deployed? Can you send output from `abra app labels baserow.domain.org`?
decentral1se changed title from when running abra app ls -S: FATA: [revision hash] is not supported to `abra app ls -S`: FATA: [hash] is not supported 2025-05-11 08:34:31 +00:00
marlon commented 2025-05-11 18:58:12 +00:00
Author
Copy Link

Here's the output.

 DEPLOYED LABELS                                                                                                                                                       
 com.docker.stack.image                                                                 baserow/baserow:1.31.1                                                         
 com.docker.stack.namespace                                                             base_domain_org                                           
 coop-cloud.base_domain_org.autoupdate                             false                                                                          
 coop-cloud.base_domain_org.chaos                                  false                                                                          
 coop-cloud.base_domain_org.recipe                                 baserow                                                                        
 coop-cloud.base_domain_org.version                                a8ae8285                                                                       
 traefik.enable                                                                         true                                                                           
 traefik.http.routers.base_domain_org.entrypoints                  web-secure                                                                     
 traefik.http.routers.base_domain_org.rule                         Host(`base.domain.org`) || HostRegexp(`{subdomain:\w+}.`) 
 traefik.http.routers.base_domain_org.tls.certresolver             production                                                                     
 traefik.http.services.base_domain_org.loadbalancer.server.port    80                                                                             
                                                                                                                                                                       
 RECIPE LABELS                                                                                                                                                         
 coop-cloud.base_domain_org.version                                1.0.0+1.31.1                                                                   
 traefik.enable                                                                         true                                                                           
 traefik.http.routers.base_domain_org.entrypoints                  web-secure                                                                     
 traefik.http.routers.base_domain_org.rule                         Host(`base.domain.org`) || HostRegexp(`{subdomain:\w+}.`) 
 traefik.http.routers.base_domain_org.tls.certresolver             production                                                                     
 traefik.http.services.base_domain_org.loadbalancer.server.port    80

fwiw I checked the recipe repo in ~/.abra/recipes/baserow and it's on tag 1.0.0+1.31.1

Here's the output. ``` DEPLOYED LABELS com.docker.stack.image baserow/baserow:1.31.1 com.docker.stack.namespace base_domain_org coop-cloud.base_domain_org.autoupdate false coop-cloud.base_domain_org.chaos false coop-cloud.base_domain_org.recipe baserow coop-cloud.base_domain_org.version a8ae8285 traefik.enable true traefik.http.routers.base_domain_org.entrypoints web-secure traefik.http.routers.base_domain_org.rule Host(`base.domain.org`) || HostRegexp(`{subdomain:\w+}.`) traefik.http.routers.base_domain_org.tls.certresolver production traefik.http.services.base_domain_org.loadbalancer.server.port 80 RECIPE LABELS coop-cloud.base_domain_org.version 1.0.0+1.31.1 traefik.enable true traefik.http.routers.base_domain_org.entrypoints web-secure traefik.http.routers.base_domain_org.rule Host(`base.domain.org`) || HostRegexp(`{subdomain:\w+}.`) traefik.http.routers.base_domain_org.tls.certresolver production traefik.http.services.base_domain_org.loadbalancer.server.port 80 ``` fwiw I checked the recipe repo in ~/.abra/recipes/baserow and it's on tag `1.0.0+1.31.1`
🎉 1
decentral1se commented 2025-05-16 16:46:45 +00:00
Owner
Copy Link

@marlon I am gonna look into this but I think if you have a chaos deploy which successfully runs, it will be commited to your .env. Then, when you run abra app deploy, it will select that chaos commit version? I need to check this. I think #549 created a bug that I can fix but maybe there is another bug here that chaos commits are being carried into regular abra app deploy invocations?

@marlon I am gonna look into this but I think if you have a chaos deploy which successfully runs, it will be commited to your `.env`. Then, when you run `abra app deploy`, it will select that chaos commit version? I need to check this. I think https://git.coopcloud.tech/toolshed/abra/pulls/549 created a bug that I can fix but maybe there is another bug here that chaos commits are being carried into regular `abra app deploy` invocations?
marlon commented 2025-05-21 17:34:17 +00:00
Author
Copy Link

Oh, you're right that the deployment in question has TYPE=baserow:a8ae8285 in its .env

Perhaps this is ranging from the original bug now, but if I undeploy and then use config to change the .env to just TYPE=baserow, then when I deploy again the correct version tag is used. After that abra app ls -S works fine.
So I was able to fix the problem manually this way, at least!

Oh, you're right that the deployment in question has `TYPE=baserow:a8ae8285` in its `.env` Perhaps this is ranging from the original bug now, but if I `undeploy` and then use `config` to change the `.env` to just `TYPE=baserow`, then when I `deploy` again the correct version tag is used. After that `abra app ls -S` works fine. So I was able to fix the problem manually this way, at least!
👍 2
decentral1se commented 2025-05-23 08:37:44 +00:00
Owner
Copy Link

@marlon yeh I was really wondering what people would make of that workflow. I kinda just realised it was necessary some time after a change by #493 I believe? @p4u1 @3wordchant are you also doing this workflow by editing the .env with config? I think this change was implemented after a discussion you had. I still didn't get time to investigate but more input is very much appreciated while we figure this one out.

@marlon yeh I was really wondering what people would make of that workflow. I kinda just realised it was necessary some time after a change by https://git.coopcloud.tech/toolshed/abra/pulls/493 I believe? @p4u1 @3wordchant are you also doing this workflow by editing the `.env` with config? I think this change was implemented after a discussion you had. I still didn't get time to investigate but more input is very much appreciated while we figure this one out.
3wordchant commented 2025-05-26 12:37:32 +00:00
Owner
Copy Link

.. are you also doing this workflow by editing the .env with config?

I've had to do that a couple of times to escape from abra trying to deploy the wrong version, but I don't think I've had to do that as standard to switch from chaos to non-chaos deployments, if that's what you're asking.

> .. are you also doing this workflow by editing the `.env` with config? I've had to do that a couple of times to escape from abra trying to deploy the wrong version, but I don't think I've had to do that as standard to switch from chaos to non-chaos deployments, if that's what you're asking.
decentral1se added the
critical fix
 label 2025-06-05 12:22:44 +00:00
3wordchant self-assigned this 2025-06-30 15:02:21 +00:00
3wordchant commented 2025-09-02 19:26:47 +00:00
Owner
Copy Link

Indeed I can reproduce this:

➜ 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 ┃ 298401b2 ┃ 298401b2     ┃ latest  ┃ false      ┃
┃ traefik   ┃ traefik.swarm-test.autonomic.zone ┃ swarm-test.autonomic.zone ┃ deployed ┃ false    ┃ 3.5.0+v3.5.0 ┃ latest  ┃ false      ┃
┃ wordpress ┃ mmtest.swarm-test.autonomic.zone  ┃ swarm-test.autonomic.zone ┃ unknown  ┃ unknown  ┃ unknown      ┃ unknown ┃ unknown    ┃
┗━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━┻━━━━━━━━━━┻━━━━━━━━━━━━━━┻━━━━━━━━━┻━━━━━━━━━━━━┛
ghost on  main 
➜ abra app undeploy ghost-demo 
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                   UNDEPLOY OVERVIEW                   ┃
┃                                                       ┃
┃ DOMAIN                ghost.swarm-test.autonomic.zone ┃
┃ RECIPE                ghost                           ┃
┃ SERVER                swarm-test.autonomic.zone       ┃
┃ CONFIG                compose.yml                     ┃
┃                                                       ┃
┃ CURRENT DEPLOYMENT    298401b2                        ┃
┃ ENV VERSION           298401b2                        ┃
┃ NEW DEPLOYMENT        N/A                             ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
? proceed? Yes
INFO initialising undeploy
INFO polling undeploy status
INFO undeploy succeeded 🟢
ghost on  main took 11s 
➜ abra app deploy ghost-demo 
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                  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
FATA version 298401b2 is not supported (matched: ^[a-f0-9]{7,40}$)
Indeed I can reproduce this: ``` ➜ 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 ┃ 298401b2 ┃ 298401b2 ┃ latest ┃ false ┃ ┃ traefik ┃ traefik.swarm-test.autonomic.zone ┃ swarm-test.autonomic.zone ┃ deployed ┃ false ┃ 3.5.0+v3.5.0 ┃ latest ┃ false ┃ ┃ wordpress ┃ mmtest.swarm-test.autonomic.zone ┃ swarm-test.autonomic.zone ┃ unknown ┃ unknown ┃ unknown ┃ unknown ┃ unknown ┃ ┗━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━━━━━━━━━━━━━┻━━━━━━━━━━┻━━━━━━━━━━┻━━━━━━━━━━━━━━┻━━━━━━━━━┻━━━━━━━━━━━━┛ ghost on  main ➜ abra app undeploy ghost-demo ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ UNDEPLOY OVERVIEW ┃ ┃ ┃ ┃ DOMAIN ghost.swarm-test.autonomic.zone ┃ ┃ RECIPE ghost ┃ ┃ SERVER swarm-test.autonomic.zone ┃ ┃ CONFIG compose.yml ┃ ┃ ┃ ┃ CURRENT DEPLOYMENT 298401b2 ┃ ┃ ENV VERSION 298401b2 ┃ ┃ NEW DEPLOYMENT N/A ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ? proceed? Yes INFO initialising undeploy INFO polling undeploy status INFO undeploy succeeded 🟢 ghost on  main took 11s ➜ abra app deploy ghost-demo ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ 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 FATA version 298401b2 is not supported (matched: ^[a-f0-9]{7,40}$) ```
👀 1
3wordchant commented 2025-09-02 19:27:16 +00:00
Owner
Copy Link

In summary:

  1. Chaos deploy
  2. undeploy
  3. deploy (without chaos)
  4. abra app ls -S
In summary: 1. Chaos `deploy` 2. `undeploy` 3. `deploy` (without chaos) 4. `abra app ls -S`
👍 1
3wordchant commented 2025-09-02 19:30:14 +00:00
Owner
Copy Link

The problem appears to be that coop-cloud.ghost-demo.chaos=false on the re-deploy in step 3.

The problem appears to be that `coop-cloud.ghost-demo.chaos=false` on the re-deploy in step 3.
👀 1
3wordchant commented 2025-09-02 19:36:48 +00:00
Owner
Copy Link

@decentral1se (or anyone), what do you think of this solution? We could alternatively set the chaos label to true if app.Recipe.EnsureVersion returns that the version is chaos-y – but only setting that flag for manual chaos deployments seems a little cleaner to me.

@decentral1se (or anyone), what do you think of this solution? We could alternatively set the `chaos` label to `true` if `app.Recipe.EnsureVersion` returns that the version is chaos-y – but only setting that flag for manual chaos deployments seems a little cleaner to me.
👍 1
decentral1se commented 2025-09-02 22:03:22 +00:00
Owner
Copy Link

OK, I think I'm following and this seems like a very solid fix indeed. Is it the case that the app deploy (no chaos) is carrying the previously chaotic version into the new deployment based on the env version? That seems actually like quite a serious bug? Maybe people are relying on this behaviour now tho.... this would then be a breaking change! I think it's a good one tho. It would be great to have an integration test for this to avoid regressions in the future.

OK, I think I'm following and this seems like a very solid fix indeed. Is it the case that the `app deploy` (no chaos) is carrying the previously chaotic version into the new deployment based on the env version? That seems actually like quite a serious bug? Maybe people are relying on this behaviour now tho.... this would then be a breaking change! I think it's a good one tho. It would be great to have an integration test for this to avoid regressions in the future.
decentral1se moved this to In Progress in Abra v0.11.x on 2025-09-02 22:17:41 +00:00
decentral1se commented 2025-09-02 22:28:06 +00:00
Owner
Copy Link

Also, I think with #626 you can still get from undeployed chaos to latest version (or specific version) by just passing some flags/args and not always having to edit the version in the .env file. This tests covers it:

tests/integration/app_deploy.bats Lines 429 to 452 in e1f029d2db
# bats test_tags=slow
@test "deploy latest after chaos deploy" {
latestRelease=$(_latest_release)
run bash -c "echo foo >> $ABRA_DIR/recipes/$TEST_RECIPE/foo"
assert_success
assert_exists "$ABRA_DIR/recipes/$TEST_RECIPE/foo"
run $ABRA app deploy "$TEST_APP_DOMAIN" \
--no-input --no-converge-checks --chaos
assert_success
_reset_recipe
assert_not_exists "$ABRA_DIR/recipes/$TEST_RECIPE/foo"
run $ABRA app deploy "$TEST_APP_DOMAIN" \
--no-input --no-converge-checks --force --latest
assert_success
assert_output --partial "$latestRelease"
run grep -q "TYPE=$TEST_RECIPE:$latestRelease" \
"$ABRA_DIR/servers/$TEST_SERVER/$TEST_APP_DOMAIN.env"
assert_success
}

Also, I think with https://git.coopcloud.tech/toolshed/abra/pulls/626 you can still get from undeployed chaos to latest version (or specific version) by just passing some flags/args and not always having to edit the version in the `.env` file. This tests covers it: https://git.coopcloud.tech/toolshed/abra/src/commit/e1f029d2db08df9627b8d86fa8dcb92334adef85/tests/integration/app_deploy.bats#L429-L452
3wordchant commented 2025-09-02 22:37:05 +00:00
Owner
Copy Link

Is it the case that the app deploy (no chaos) is carrying the previously chaotic version into the new deployment based on the env version?

Yep, exactly. I think this is arguably "expected", because operator-sync-wise, if I deploy a chaos version, then you pull the repo with the env file and redeploy, it shouldn't silently go back to a released version either.

But yes, seems risky and I think bailing on non-chaos deploy is the least-wrong thing to do here.

It would be great to have an integration test for this to avoid regressions in the future.

I will make it so.

> Is it the case that the `app deploy` (no chaos) is carrying the previously chaotic version into the new deployment based on the env version? Yep, exactly. I think this is arguably "expected", because operator-sync-wise, if I deploy a chaos version, then you pull the repo with the env file and redeploy, it shouldn't silently go back to a released version either. But yes, seems risky and I think bailing on non-chaos deploy is the least-wrong thing to do here. > It would be great to have an integration test for this to avoid regressions in the future. I will make it so.
👍 1 ❤️ 1
decentral1se moved this to Done in Abra v0.11.x on 2025-09-04 08:14:28 +00:00
3wordchant commented 2025-09-08 18:52:04 +00:00
Owner
Copy Link

Alternative solution (see #646 ) – make sure we set chaos label if we're redeploying a hash version.

Alternative solution (see #646 ) – make sure we set `chaos` label if we're redeploying a hash version.
👍 1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is not working
build
go build related issues
ci/cd
Building things with CI/CD
critical fix
https://docs.coopcloud.tech/federation/resolutions/passed/010/
design
UI/UX
documentation
Documenting all the things
duplicate
This issue or pull request already exists
enhancement
New feature
help wanted
Need some help
i10n
Everything to do with localisation
i18n
Everything to do with internationalisation
invalid
Something is wrong
question
More information is needed
release
Release management
release-candidate
Related to the new release candidate
security
Security related
test
Unit/integration testing
wontfix
This won't be fixed
No Label
bug
critical fix
Milestone
No items
No Milestone
Projects
Clear projects
No project Abra v0.11.x
Assignees
Clear assignees
3wordchant abra-bot ammaratef45 Apfelwurm carla cas coopcloud cyrnel decentral1se fauno jmakdah2 kawaiipunk knoflook lambdabundesverband mac-chaffee moritz p4u1 ripclap simon sixsmith trav val yksflip
No Assignees 3wordchant
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/abra#554
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?