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

feat: force a deploy to latest release / --ignore-env-version #617

New Issue
Closed
opened 2025-08-26 16:33:58 +00:00 by iexos · 5 comments
iexos commented 2025-08-26 16:33:58 +00:00
Contributor
Copy Link

I would like to use abra app deploy <domain> latest to directly deploy to the latest release. This would make it much simpler to deploy if

  • app is currently undeployed on an old version
  • app is chaos (un)deployed and I want to go back to upstream

Both of these cases are relevant to me for writing scripts to help with recipe upgrade testing, but also when doing it manually.

I would like to use `abra app deploy <domain> latest` to directly deploy to the latest release. This would make it much simpler to deploy if * app is currently undeployed on an old version * app is chaos (un)deployed and I want to go back to upstream Both of these cases are relevant to me for writing scripts to help with recipe upgrade testing, but also when doing it manually.
decentral1se commented 2025-08-27 12:38:40 +00:00
Owner
Copy Link

@iexos abra app deploy <domain> --ignore-env-version/-i will deploy the latest by default, ignoring the .env version. If it's already deployed, you can --force/-f? I am not sure about the interaction with --chaos/-C off the top of my head, but if you test the combinations manually, I'd be curious to see what you run into! The abra app deploy code path makes sure to pull the latest from the recipe repository, so it should be up-to-date.

@iexos `abra app deploy <domain> --ignore-env-version/-i` will deploy the latest by default, ignoring the `.env` version. If it's already deployed, you can `--force/-f`? I am not sure about the interaction with `--chaos/-C` off the top of my head, but if you test the combinations manually, I'd be curious to see what you run into! The `abra app deploy` code path makes sure to pull the latest from the recipe repository, so it should be up-to-date.
decentral1se added the
question
 label 2025-08-27 12:39:31 +00:00
decentral1se commented 2025-08-27 12:42:28 +00:00
Owner
Copy Link

abra recipe versions <recipe> -m will give you insight into the catalogue versions.

Some of these things can also be arranged with standard tools, e.g. if you want to investigate the catalogue.

abra catalogue sync  # only available HEAD, or git pull yourself
jq -r '.gitea.versions[-1] | keys[0]' < "$ABRA_DIR/catalogue/recipes.json"

That'll get you the latest published gitea version.

`abra recipe versions <recipe> -m` will give you insight into the catalogue versions. Some of these things can also be arranged with standard tools, e.g. if you want to investigate the catalogue. ``` abra catalogue sync # only available HEAD, or git pull yourself jq -r '.gitea.versions[-1] | keys[0]' < "$ABRA_DIR/catalogue/recipes.json" ``` That'll get you the latest published gitea version.
iexos commented 2025-08-27 16:08:36 +00:00
Author
Contributor
Copy Link

Ah thank you, --ignore-env-version does exactly what I want for undeployed apps! Is there another use for this apart from deploying the latest version? Maybe something in the docs/help could make it more obvious.

For a chaos deployed app this happens:

$ abra app deploy <domain> -i -f`
FATA unable to resolve 'ba5f404e+U': reference not found

I guess it ignores the .env version, but it can still get the version from deployment?

Ah thank you, `--ignore-env-version` does exactly what I want for undeployed apps! Is there another use for this apart from deploying the latest version? Maybe something in the docs/help could make it more obvious. For a chaos deployed app this happens: ``` $ abra app deploy <domain> -i -f` FATA unable to resolve 'ba5f404e+U': reference not found ``` I guess it ignores the .env version, but it can still get the version from deployment?
decentral1se commented 2025-08-28 09:25:40 +00:00
Owner
Copy Link

Is there another use for this apart from deploying the latest version? Maybe something in the docs/help could make it more obvious.

Actually, I'm not sure. I think maybe not? If you pass <version> to abra app deploy, i think -i is implicit?

I guess for abra app upgrade, you have a different behaviour but I don't think that is even tested 🙈

This flag was added a bit "on the end" of the large env version refactor... i'm glad you're asking this question!

If you have some more spoons for manual testing, maybe you can see what it does for different scenarios? Maybe the name of the flag could be better. Maybe docs could be better. I'm not sure.

update: It's only used for abra app deploy!

FATA unable to resolve 'ba5f404e+U': reference not found
I guess it ignores the .env version, but it can still get the version from deployment?

Ah yes, that does seem like a bug. Let's put this on the stack to fix.

> Is there another use for this apart from deploying the latest version? Maybe something in the docs/help could make it more obvious. Actually, I'm not sure. I think maybe not? If you pass `<version>` to `abra app deploy`, i think `-i` is implicit? ~~I guess for `abra app upgrade`, you have a different behaviour but I don't think that is even tested 🙈~~ This flag was added a bit "on the end" of the large env version refactor... i'm glad you're asking this question! ~~If you have some more spoons for manual testing, maybe you can see what it does for different scenarios? Maybe the name of the flag could be better. Maybe docs could be better. I'm not sure.~~ **update**: It's only used for `abra app deploy`! > FATA unable to resolve 'ba5f404e+U': reference not found > I guess it ignores the .env version, but it can still get the version from deployment? Ah yes, that does seem like a bug. Let's put this on the stack to fix.
decentral1se added this to the Abra v0.11.x project 2025-08-28 09:26:46 +00:00
decentral1se added the
bug
 label 2025-08-28 09:48:11 +00:00
decentral1se commented 2025-08-29 08:40:40 +00:00
Owner
Copy Link

Ah, I've dug into this a bit. Gonna DM you to figure out the rest and report back with a plan.

update: We're gonna try rename it to --latest 🫡

~~Ah, I've dug into this a bit. Gonna DM you to figure out the rest and report back with a plan.~~ **update**: We're gonna try rename it to `--latest` 🫡
decentral1se changed title from deploy to `latest` release to feat: force a deploy to `latest` release / `--ignore-env-version` 2025-08-29 08:42:39 +00:00
decentral1se moved this to In Progress in Abra v0.11.x on 2025-08-29 08:42:58 +00:00
decentral1se moved this to Done in Abra v0.11.x on 2025-08-29 14:43:55 +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
i10n
Everything to do with localisation
i18n
Everything to do with internationalisation
invalid
Something is wrong
meta
relating to the project or repo itself
question
More information is needed
red abya yala
Work funded by Calyx institute for Red Abya Yala
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
question
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 decentral1se fauno jmakdah2 kawaiipunk knoflook lambdabundesverband moritz p4u1 ripclap simon sixsmith trav val yksflip
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: toolshed/abra#617
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?