Upgrade env config only #440

New Issue

2023-04-06T15:49:18Z

moritz commented

2023-04-06 15:49:18 +00:00

It would be nice to have a way to change the .env config without executing abra app undeploy and abra app deploy again, which can lead to hidden upgrades: coop-cloud/organising#434
Something like abra app upgrade --env / -E

The actual way is to run abra app ls -S to find out the current version. Checkout the recipe repo into this version and then run abra app upgrade -C. This could be combined into one command.

It would be nice to have a way to change the .env config without executing `abra app undeploy` and `abra app deploy` again, which can lead to hidden upgrades: https://git.coopcloud.tech/coop-cloud/organising/issues/434 Something like `abra app upgrade --env / -E` The actual way is to run `abra app ls -S` to find out the current version. Checkout the recipe repo into this version and then run `abra app upgrade -C`. This could be combined into one command.

moritz added the enhancement label 2023-04-06 15:49:18 +00:00

decentral1se commented

2023-04-10 11:00:36 +00:00

@moritz I'm not sure I understand this one. What in the .env do you want to update? You are mentioning versions but no versioning information is currently stored in the .env files?

For the version deployment issues, yeh, that is a pain currently. You could upgrade/rollback currently but then there is no auto-complete on the versions. I think coop-cloud/organising#204 would solve this?

You can also use abra app version. I just checked that and it says in the --help:

Show all information about versioning related to a deployed app. This includes
the individual image names, tags and digests. But also the Co-op Cloud recipe
version.

But actually, I don't think that's correct. I'll open a separate ticket.

@moritz I'm not sure I understand this one. What in the `.env` do you want to update? You are mentioning versions but no versioning information is currently stored in the `.env` files? For the version deployment issues, yeh, that is a pain currently. You could `upgrade`/`rollback` currently but then there is no auto-complete on the versions. I think https://git.coopcloud.tech/coop-cloud/organising/issues/204 would solve this? You can also use `abra app version`. I just checked that and it says in the `--help`: > Show all information about versioning related to a deployed app. This includes the individual image names, tags and digests. But also the Co-op Cloud recipe version. But actually, I don't think that's correct. I'll open a separate ticket.

decentral1se referenced this issue

2023-04-10 11:03:26 +00:00

`abra app version` doesn't match help description #442

moritz commented

2023-04-12 07:35:22 +00:00

@moritz I'm not sure I understand this one. What in the .env do you want to update? You are mentioning versions but no versioning information is currently stored in the .env files?

abra app upgrade only works if there is a new version, but often I want to update only the .env configuration without changing the deployed version and without undeploying everything. Therefore I thought something like abra app upgrade --env / -E would be nice. Or maybe abra app env-update to avoid any confusion with version upgrades.

The actual way is to run abra app ls -S to find out the current version. Checkout the recipe repo into this version and then run abra app upgrade -C. This could be combined into one command.

Using this workaround I can update env variables and only the container that are affected by the changes are restarted.

> @moritz I'm not sure I understand this one. What in the `.env` do you want to update? You are mentioning versions but no versioning information is currently stored in the `.env` files? `abra app upgrade` only works if there is a new version, but often I want to update only the .env configuration without changing the deployed version and without undeploying everything. Therefore I thought something like `abra app upgrade --env / -E` would be nice. Or maybe `abra app env-update` to avoid any confusion with version upgrades. > The actual way is to run `abra app ls -S` to find out the current version. Checkout the recipe repo into this version and then run `abra app upgrade -C`. This could be combined into one command. Using this workaround I can update env variables and only the container that are affected by the changes are restarted.

decentral1se referenced this issue

2023-04-12 09:29:18 +00:00

abra app upgrade -f reports "no published release discovered" #444

decentral1se commented

2023-04-12 09:39:16 +00:00

abra app upgrade only works if there is a new version, but often I want to update only the .env configuration without changing the deployed version and without undeploying everything ... I can update env variables and only the container that are affected by the changes are restarted.

I was going to say, "isn't this upgrade --force / deploy --force"? But then I ran into coop-cloud/organising#444 🙃

I thought deploy --force does this?

You still have to manually manage the versions carefully because coop-cloud/organising#434 / coop-cloud/organising#204 are not solved. We should get around to this soon.

> abra app upgrade only works if there is a new version, but often I want to update only the .env configuration without changing the deployed version and without undeploying everything ... I can update env variables and only the container that are affected by the changes are restarted. I was going to say, "isn't this `upgrade --force` / `deploy --force`"? But then I ran into https://git.coopcloud.tech/coop-cloud/organising/issues/444 🙃 I thought `deploy --force` does this? You still have to manually manage the versions carefully because https://git.coopcloud.tech/coop-cloud/organising/issues/434 / https://git.coopcloud.tech/coop-cloud/organising/issues/204 are not solved. We should get around to this soon.

moritz commented

2023-04-12 13:54:00 +00:00

Nice upgrade --force / deploy --force is almost doing what I want, despite the version issue. Is there a difference between these two commands? Also between upgrade -C / deploy -C ? This is a bit confusing.

Nice `upgrade --force / deploy --force` is almost doing what I want, despite the version issue. Is there a difference between these two commands? Also between `upgrade -C / deploy -C` ? This is a bit confusing.

decentral1se commented

2023-04-12 18:00:52 +00:00

Is there a difference between these two commands? Also between upgrade -C / deploy -C ? This is a bit confusing.

Yeh, this was some early UI/UX that nobody really questioned until now 😆 I'm pretty sure both of those are exactly the same but I haven't checked the code again. Maybe we should make change here... you can't force the upgrade? 🤷‍♀️

> Is there a difference between these two commands? Also between upgrade -C / deploy -C ? This is a bit confusing. Yeh, this was some early UI/UX that nobody really questioned until now 😆 I'm pretty sure both of those are exactly the same but I haven't checked the code again. Maybe we should make change here... you can't force the upgrade? 🤷‍♀️

decentral1se added this to the (deleted) project 2023-06-08 09:27:39 +00:00

moritz referenced this issue

2023-10-03 13:17:46 +00:00

Collective maintenance often means hidden app upgrades #434

decentral1se commented

2023-10-05 12:53:06 +00:00

OK, let's converge on #434 following coop-cloud/organising#434 (comment). Gathering energy for a speedrun...

OK, let's converge on #434 following https://git.coopcloud.tech/coop-cloud/organising/issues/434#issuecomment-18089. Gathering energy for a speedrun...

decentral1se closed this issue

2023-10-05 12:53:11 +00:00

decentral1se commented

2023-10-06 17:31:34 +00:00

Also, you can now do abra app version <domain> and get the version and then run: abra app deploy <domain> <version> -fwhich is more repeatable. Hopefully with pinned & synced versions, this will more automated in the future.

Also, you can now do `abra app version <domain>` and get the version and then run: `abra app deploy <domain> <version> -f`which is more repeatable. Hopefully with pinned & synced versions, this will more automated in the future.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#440