abra app upgrade: show a diff of new .env.sample and the servers .env #337

New Issue

yksflip · 2022-08-05T13:49:04Z

yksflip commented

2022-08-05 13:49:04 +00:00

When adding new env variables there's atm no way to ensure they get into operators servers/.env except of release notes.
Maybe a simple way could be showing a diff of the to be upgraded .env.sample and servers/.env?

Or even more sophisticated parse the .envs and add new stuff automagically and just inform about it?

When adding new env variables there's atm no way to ensure they get into operators `servers/.env` except of release notes. Maybe a simple way could be showing a diff of the to be upgraded `.env.sample` and `servers/.env`? Or even more sophisticated parse the .envs and add new stuff automagically and just inform about it?

yksflip added the

enhancement

abra

labels 2022-08-05 13:49:04 +00:00

decentral1se commented

2022-08-09 13:52:56 +00:00

@yksflip

Maybe a simple way could be showing a diff of the to be upgraded .env.sample and servers/.env?

Oh nice, do you mean in the abra app upgrade ... flow? So, like, diffing the current tag and last tag of the recipe .env.sample? That does assume those are maintained by the recipe maintainer which is til now something implicit. We could try to formalise that.

abra app check ... does try to do this afair. Maybe we could add a message to the upgrade flow to say "do run that to be sure"? Idk about adding an automatic check which might fail the upgrade flow? What if the recipe maintainer just made a mistake and then the operator is blocked?

Another idea is to add this check to deploy with a --no-env-checks? That would be making deploy more strict... but would follow the logic of domain and git changes checking... unsure...

Or even more sophisticated parse the .envs and add new stuff automagically and just inform about it?

Hmmmm I think I'd be uncomfortable with auto-appending values into operators .env configs. I could image we'd be breaking peoples shit if they were moving fast and didn't read the message telling them we auto-updated their stuff?

@yksflip > Maybe a simple way could be showing a diff of the to be upgraded .env.sample and servers/.env? Oh nice, do you mean in the `abra app upgrade ...` flow? So, like, diffing the current tag and last tag of the recipe `.env.sample`? That does assume those are maintained by the recipe maintainer which is til now something implicit. We could try to formalise that. `abra app check ...` does try to do this afair. Maybe we could add a message to the upgrade flow to say "do run that to be sure"? Idk about adding an automatic check which might fail the upgrade flow? What if the recipe maintainer just made a mistake and then the operator is blocked? Another idea is to add this check to deploy with a `--no-env-checks`? That would be making `deploy` more strict... but would follow the logic of domain and git changes checking... unsure... > Or even more sophisticated parse the .envs and add new stuff automagically and just inform about it? Hmmmm I think I'd be uncomfortable with auto-appending values into operators `.env` configs. I could image we'd be breaking peoples shit if they were moving fast and didn't read the message telling them we auto-updated their stuff?

decentral1se added this to the (deleted) project 2022-08-09 13:53:42 +00:00

decentral1se commented

2023-06-08 09:31:38 +00:00

Let's converge on coop-cloud/organising#446

Let's converge on https://git.coopcloud.tech/coop-cloud/organising/issues/446

decentral1se closed this issue

2023-06-08 09:31:39 +00:00

Sign in to join this conversation.