Checking for env changes #446

New Issue

moritz · 2023-04-14T15:33:56Z

moritz commented

2023-04-14 15:33:56 +00:00

When upgrading apps I run vimdiff between the app .env file and the recipe .env.sample to check for changes and apply them.
It would be nice if this could be integrated into abra.
Either an extra command like abra app diffconf or automatically checking changes at each upgrade and deploy.

A good practice way would be to only comment out variables in the .env instead of deleting them, then abra could detect missing variables and insert them automatically commented out.

I would also favor if new recipe releases never contain new "required" env variables. Each new env variable should be set to a default value, so that missing them does not break anything.

When upgrading apps I run vimdiff between the app `.env` file and the recipe `.env.sample` to check for changes and apply them. It would be nice if this could be integrated into abra. Either an extra command like `abra app diffconf` or automatically checking changes at each upgrade and deploy. A good practice way would be to only comment out variables in the `.env` instead of deleting them, then abra could detect missing variables and insert them automatically commented out. I would also favor if new recipe releases never contain new "required" env variables. Each new env variable should be set to a default value, so that missing them does not break anything.

moritz added the

enhancement

label 2023-04-14 15:33:56 +00:00

moritz changed title from ~~checking for env diffs~~ to checking for env changes

2023-04-14 15:41:40 +00:00

decentral1se commented

2023-04-14 17:04:53 +00:00

Related #359

A good practice way would be to only comment out variables in the .env instead of deleting them, then abra could detect missing variables and insert them automatically commented out.

I would also favor if new recipe releases never contain new "required" env variables. Each new env variable should be set to a default value, so that missing them does not break anything.

Yeh I like both of thoses ideas but struggle to understand how we'll account for a diversity of recipe maintainers doing "their own thing". I like to delete all unused env vars to keep my .env as small as possible. But I could see the benefit to keeping them if this worked.

Recipe maintenance can be pretty messy some times... and we have the versioning scheme to signal breaking changes? One way to show that there are breaking changes coming is to put stuff in the release notes, e.g. https://git.coopcloud.tech/coop-cloud/matrix-synapse/src/branch/main/release/3.0.0+v1.74.0

I think @yksflip once suggested to include a diff output in the upgrade prompt which might be a way to go. A separate command also sounds good to me.

Related https://git.coopcloud.tech/coop-cloud/organising/issues/359 > A good practice way would be to only comment out variables in the .env instead of deleting them, then abra could detect missing variables and insert them automatically commented out. > > I would also favor if new recipe releases never contain new "required" env variables. Each new env variable should be set to a default value, so that missing them does not break anything. Yeh I like both of thoses ideas but struggle to understand how we'll account for a diversity of recipe maintainers doing "their own thing". I like to delete all unused env vars to keep my `.env` as small as possible. But I could see the benefit to keeping them if this worked. Recipe maintenance can be pretty messy some times... and we have the versioning scheme to signal breaking changes? One way to show that there are breaking changes coming is to put stuff in the release notes, e.g. https://git.coopcloud.tech/coop-cloud/matrix-synapse/src/branch/main/release/3.0.0+v1.74.0 I think @yksflip once suggested to include a diff output in the `upgrade` prompt which might be a way to go. A separate command also sounds good to me.

decentral1se changed title from ~~checking for env changes~~ to Checking for env changes

2023-04-20 06:42:00 +00:00

decentral1se commented

2023-04-20 06:45:41 +00:00

@moritz I just saw https://github.com/aymanbagabas/go-udiff and it looks likes kinda handy for this:

package main

import (
  "fmt"

  "github.com/aymanbagabas/go-udiff"
)

func main() {
  a := "Hello, world!\n"
  b := "Hello, Go!\nSay hi to µDiff"
  d := udiff.Unified("a.txt", "b.txt", a, b)
  fmt.Println(d)
}

--- a.txt
+++ b.txt
@@ -1 +1,2 @@
-Hello, world!
+Hello, Go!
+Say hi to µDiff
\ No newline at end of file

Could there perhaps be a way to parse both the .env.sample, $domain.env to only get the uncommented env vars being used and then feed them into this diff function? Delimiting with a newline might give the right output.

Then we wouldn't have to mandate that operators keep their .env files matching or never delete stuff or whatever, we just diff against "in use" env vars?

This would be a simpler model perhaps for maintainers also. If you introduce an uncommented env var into the .env.sample, then it will get diffed.

abra app config [--diff] and potentially showing this on abra app deploy/upgrade?

@moritz I just saw https://github.com/aymanbagabas/go-udiff and it looks likes kinda handy for this: ```go package main import ( "fmt" "github.com/aymanbagabas/go-udiff" ) func main() { a := "Hello, world!\n" b := "Hello, Go!\nSay hi to µDiff" d := udiff.Unified("a.txt", "b.txt", a, b) fmt.Println(d) } ``` ``` --- a.txt +++ b.txt @@ -1 +1,2 @@ -Hello, world! +Hello, Go! +Say hi to µDiff \ No newline at end of file ``` Could there perhaps be a way to parse both the `.env.sample`, `$domain.env` to only get the uncommented env vars being used and then feed them into this diff function? Delimiting with a newline might give the right output. Then we wouldn't have to mandate that operators keep their `.env` files matching or never delete stuff or whatever, we just diff against "in use" env vars? This would be a simpler model perhaps for maintainers also. If you introduce an uncommented env var into the `.env.sample`, then it will get diffed. `abra app config [--diff]` and potentially showing this on `abra app deploy/upgrade`?

decentral1se added this to the Medium/large enhancements project 2023-06-08 09:25:53 +00:00

decentral1se referenced this issue

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

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

decentral1se commented

2023-07-19 22:00:05 +00:00

/cc @nicksellen re: "One thing (aside from me reading the maintainers manual) that might be useful is something to check/update/validate the env configs when there are upgrades/changes..." from https://codeberg.org/bath.social/server/wiki/2023-07-19-Upgrade-tales

decentral1se self-assigned this 2023-10-04 13:28:30 +00:00

decentral1se referenced this issue from a commit

2023-10-05 22:39:21 +00:00

WIP: improve app check

decentral1se referenced this issue from coop-cloud/abra

2023-10-05 22:39:31 +00:00

fix: improve app check #369

decentral1se commented

2023-10-05 22:41:10 +00:00

Lol ok app check has worked like this all along 🙃 Just need to improve the output & add a warning to the deploy/upgrade flow for flagging when env vars are missing. Then I think it would be a good idea to document our thoughts from here and close off #359

Lol ok `app check` has worked like this all along 🙃 Just need to improve the output & add a warning to the deploy/upgrade flow for flagging when env vars are missing. Then I think it would be a good idea to document our thoughts from here and close off https://git.coopcloud.tech/coop-cloud/organising/issues/359

😆 1

decentral1se referenced this issue from a commit

2023-10-06 08:56:49 +00:00

fix: improve app check

decentral1se closed this issue

2023-10-06 09:02:39 +00:00

Sign in to join this conversation.