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

Closed
opened 2022-08-05 13:49:04 +00:00 by yksflip · 2 comments
Owner

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
Owner

@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
Owner

Let's converge on #446

Let's converge on https://git.coopcloud.tech/coop-cloud/organising/issues/446
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#337
No description provided.