toolshed/abra
4
2
Fork 18
Code Issues 34 Pull Requests 3 Packages Releases 40 Activity

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

New Issue
Open
opened 2025-05-10 02:04:11 +00:00 by marlon · 7 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 "next" project 2025-05-11 08:24:34 +00:00
decentral1se moved this to In Progress in Abra "next" on 2025-05-11 08:24:48 +00:00
decentral1se moved this to Backlog in Abra "next" 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
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
contributing
Dealing with contributing
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
invalid
Something is wrong
meta
relating to the project or repo itself
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 "next"
Assignees
Clear assignees
3wordchant abra-bot ammaratef45 Apfelwurm carla cas decentral1se fauno kawaiipunk knoflook lambdabundesverband moritz p4u1 simon 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?