abra app ls -S: FATA: [hash] is not supported
#554
Closed
opened 2025-05-10 02:04:11 +00:00 by marlon
·
15 comments
No Branch/Tag Specified
main
renovate/golang-1.27
renovate/github.com-charmbracelet-bubbletea-2.x
fix/492
local-integration-testing
renovate/github.com-charmbracelet-lipgloss-2.x
renovate/otel-weaver-0.x
renovate/codespell-2.x
renovate/tonistiigi-xx-1.x
renovate/alpine-3.x
renovate/github.com-charmbracelet-log-2.x
chore-deps
fix/deps
fix/613
0.13.0-beta
0.13.0-rc2-beta
0.13.0-rc1-beta
0.12.0-beta
0.11.0-beta
0.10.1-beta
0.10.0-beta
0.10.0-rc2-beta
0.10.0-rc1-beta
0.9.0-beta
0.8.1-beta
0.8.0-beta
0.8.0-rc2-beta
0.8.0-rc1-beta
0.7.0-beta
0.7.0-rc3-beta
0.7.0-rc2-beta
0.6.0-beta
0.5.1-beta
0.5.0-alpha
0.4.1-alpha
0.4.0-alpha
0.4.0-alpha-rc8
0.4.0-alpha-rc7
0.4.0-alpha-rc6
0.4.0-alpha-rc5
0.4.0-alpha-rc4
0.4.0-alpha-rc3
0.4.0-alpha-rc2
0.4.0-alpha-rc1
0.3.1-alpha-rc2
0.3.1-alpha-rc1
0.3.1-rc1
0.3.0-alpha
0.2.2-alpha
0.2.1-alpha
0.2.0-alpha
0.1.8-alpha
0.1.7-alpha
0.1.6-alpha
0.1.5-alpha
0.1.4-alpha
0.1.3-alpha
0.1.2-alpha
0.1.1-alpha
0.1.0-alpha
10.0.5
10.0.3
10.0.2
10.0.1
10.0.0
9.0.0
8.0.1
8.0.0
0.7.4
0.7.3
0.7.2
0.7.1
0.7.0
checkout
0.6.0
0.5.0
0.4.1
0.4.0
0.3.1
0.3.0
0.2.0
0.1.2
0.1.1
0.1.0
Labels
Clear labels
bug
build
ci/cd
critical fix
design
documentation
duplicate
easy-first-issue
enhancement
help wanted
i10n
i18n
installer
invalid
question
release
release-candidate
security
tech-debt
test
wontfix
Something is not working
go build related issues
Building things with CI/CD
https://docs.coopcloud.tech/federation/resolutions/passed/010/
UI/UX
Documenting all the things
This issue or pull request already exists
Something for new people to get stuck into. We hope it's easy!
New feature
Need some help
Everything to do with localisation
Everything to do with internationalisation
Everything to do with the install script.
Something is wrong
More information is needed
Release management
Related to the new release candidate
Security related
Unit/integration testing
This won't be fixed
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Abra v0.11.x
Done
Assignees
3wordchant
aadil (Aadil Ayub)
abra-bot (Abra Bot)
ammaratef45
amras (Sarma)
Apfelwurm
BornDeleuze
Brooke
carla
cas (Cassowary)
coopcloud
cyrnel
decentral1se (d1)
dede
devydave
fauno (fauno)
iexos
jade (Jade Ambrose)
jjsfunhouse
jmakdah2 (Jackie Makdah)
joe-irving (Joe Irving)
kawaiipunk (KawaiiPunk)
knoflook
kolaente
lambdabundesverband
linnealovespie (April)
moosemower
moritz
notplants
oxaliq (sorrel)
p4u1
pharaohgraphy (Andrew 🐦🔥❤️🔥✴️)
renovate-bot (Comrade Renovate Bot)
ripclap
simon
sixsmith (Sixsmith)
stevensting
trav (Trav Fryer)
val (val (he/him))
yksflip
Clear assignees
No Assignees
3wordchant
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/abra#554
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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.:
It deployed correctly but afterward, I get this error when running:
abra version 0.10.1-beta-2fbef41
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 theabra 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?when running abra app ls -S: FATA: [revision hash] is not supportedto `abra app ls -S`: FATA: [hash] is not supportedHere's the output.
fwiw I checked the recipe repo in ~/.abra/recipes/baserow and it's on tag
1.0.0+1.31.1@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 runabra 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 regularabra app deployinvocations?Oh, you're right that the deployment in question has
TYPE=baserow:a8ae8285in its.envPerhaps this is ranging from the original bug now, but if I
undeployand then useconfigto change the.envto justTYPE=baserow, then when Ideployagain the correct version tag is used. After thatabra app ls -Sworks fine.So I was able to fix the problem manually this way, at least!
@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
.envwith 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.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.
Indeed I can reproduce this:
In summary:
deployundeploydeploy(without chaos)abra app ls -SThe problem appears to be that
coop-cloud.ghost-demo.chaos=falseon the re-deploy in step 3.@decentral1se (or anyone), what do you think of this solution? We could alternatively set the
chaoslabel totrueifapp.Recipe.EnsureVersionreturns that the version is chaos-y – but only setting that flag for manual chaos deployments seems a little cleaner to me.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.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
.envfile. This tests covers it: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.
I will make it so.
Alternative solution (see #646 ) – make sure we set
chaoslabel if we're redeploying a hash version.