Support config versions sourced from upstream package env #43

Closed
opened 2020-12-07 09:48:58 +00:00 by decentral1se · 6 comments
Owner

I've noticed that when I merge a docker image tag uprade and then run abra deploy that it tells me that I need to upgrade the config version in my env file. But that really should be done by abra because the user shouldnt have to know when an upstream app repo makes changes to the configs. To do this we need to bake in some auto config sha sum generation thingy like we discussed before to inject config version values into the env from abra side. Then remove all CONF env vars from the app repo env var files.

I've noticed that when I merge a docker image tag uprade and then run `abra deploy` that it tells me that I need to upgrade the config version in my env file. But that really should be done by abra because the user shouldnt have to know when an upstream app repo makes changes to the configs. To do this we need to bake in some auto config sha sum generation thingy like we discussed before to inject config version values into the env from abra side. Then remove all CONF env vars from the app repo env var files.
Owner

I just tried this with wordpress and I didn't get an error about configs -- wondering if it's when we update the configs in the stack instead?

Either way, auto-generating config versions based on checksums sounds A+, let's do it.

I just tried this with `wordpress` and I didn't get an error about configs -- wondering if it's when we update the configs in the stack instead? Either way, auto-generating config versions based on checksums sounds A+, let's do it.
Author
Owner

wondering if it's when we update the configs in the stack instead?

Ah yes, you're right!

OK, so yes, upgrading versions is seamless if you don't touch the configs 💯

> wondering if it's when we update the configs in the stack instead? Ah yes, you're right! OK, so yes, upgrading versions is seamless if you don't touch the configs 💯
decentral1se added the
help wanted
enhancement
labels 2020-12-29 13:06:24 +00:00
Author
Owner

In a similar vein to #72, can we imagine that the config versions stop living in the .env.sample -> ~/.servers/$server/$app.env (end-user controlled) and instead live in an app packager controlled env file (e.g. .env.package or whatever) which abra knows to source when doing deployments and which the packager takes responsibility for changing instead of relying the end-user to bump vn -> vn+1?

In a similar vein to https://git.autonomic.zone/coop-cloud/abra/pulls/72, can we imagine that the config versions stop living in the `.env.sample` -> `~/.servers/$server/$app.env` (end-user controlled) and instead live in an app packager controlled env file (e.g. `.env.package` or whatever) which `abra` knows to source when doing deployments and which the packager takes responsibility for changing instead of relying the end-user to bump `vn` -> `vn+1`?
decentral1se changed title from Abra should control and upgrade the config file versioning env vars to Support config versions sourced from upstream package env 2021-01-01 18:07:14 +00:00
Owner

can we imagine that the config versions stop living in the .env.sample -> ~/.servers/$server/$app.env (end-user controlled) and instead live in an app packager controlled env file

We might possibly be able to be super-cheeky and get this working straight away, putting export SOME_CONFIG_VERSION=v2 into abra-commands.sh 😈

> can we imagine that the config versions stop living in the `.env.sample` -> `~/.servers/$server/$app.env` (end-user controlled) and instead live in an app packager controlled env file We might possibly be able to be super-cheeky and get this working straight away, putting `export SOME_CONFIG_VERSION=v2` into `abra-commands.sh` 😈
Owner

I've got this working, quick question before I run off and update all the apps: do we use the existing abra-commands.sh (and maybe rename it?), or use a new separate abra.env or something?

abra.env seems cleaner, but is also a separate file, and extra code in `abra.

I've got this working, quick question before I run off and update all the apps: do we use the existing `abra-commands.sh` (and maybe rename it?), or use a new separate `abra.env` or something? `abra.env` seems cleaner, but is also a separate file, and extra code in `abra.
Author
Owner

Great! I'm easy, whatever you think <3

Great! I'm easy, whatever you think <3
3wordchant referenced this issue from a commit 2021-02-08 13:14:38 +00:00
3wordchant referenced this issue from a commit 2021-02-08 13:19:17 +00:00
3wordchant referenced this issue from a commit 2021-02-08 13:28:29 +00:00
3wordchant referenced this issue from a commit 2021-02-08 13:29:16 +00:00
3wordchant referenced this issue from a commit 2021-02-08 13:34:19 +00:00
3wordchant referenced this issue from a commit 2021-02-08 13:39:27 +00:00
3wordchant referenced this issue from a commit 2021-02-08 13:41:07 +00:00
3wordchant referenced this issue from a commit 2021-02-08 14:01:19 +00:00
3wordchant referenced this issue from a commit 2021-02-08 14:02:37 +00:00
3wordchant referenced this issue from a commit 2021-02-08 17:50:52 +00:00
3wordchant referenced this issue from a commit 2021-02-08 17:51:16 +00:00
3wordchant referenced this issue from a commit 2021-02-08 17:52:39 +00:00
This repo is archived. You cannot comment on issues.
No Milestone
No Assignees
2 Participants
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/abra#43
No description provided.