Support config versions sourced from upstream package env #43
Labels
No Label
breaking-change
bug
CI/CD
design
documentation
duplicate
enhancement
help wanted
invalid
plugin
question
secrets
shell-completion
versioning
wontfix
No Milestone
No Assignees
2 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/abra#43
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 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.
Ah yes, you're right!
OK, so yes, upgrading versions is seamless if you don't touch the configs 💯
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) whichabra
knows to source when doing deployments and which the packager takes responsibility for changing instead of relying the end-user to bumpvn
->vn+1
?Abra should control and upgrade the config file versioning env varsto Support config versions sourced from upstream package envWe might possibly be able to be super-cheeky and get this working straight away, putting
export SOME_CONFIG_VERSION=v2
intoabra-commands.sh
😈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 separateabra.env
or something?abra.env
seems cleaner, but is also a separate file, and extra code in `abra.Great! I'm easy, whatever you think <3