abra app deploy handles re-deploy and shows env updates #712

New Issue

pharaohgraphy · 2025-11-02T01:07:26Z

pharaohgraphy commented

2025-11-02 01:07:26 +00:00

Hey all, this is my first issue here so please take it easy on me 😅

Issue

This caught me by surprise as the docs do not mention how to deal with config-only changes, but talk about managing secrets.
I automatically assumed that config would be treated the same as secrets: change it, and deploy 🙏

But abra app deploy myapp.example.com just says there's nothing new to deploy 💀
👉I found --force -f though and have been using that flag since, but it doesn't feel "right"?

Expected behaviour

My ideal DX (developer experience) would be:

Change config via app config ..
Deploy via app deploy ..
Be prompted with .env changes in summary (ideally what vars changed, but just a mention of "config updates" suffices for now!)
Confirm deploy, which ships the new .env and simply restarts the service (if that's the best way to do it?)

This approach keeps the Dev aware of what they're doing & why the app is being deployed.
It also gives peace of mind because you're always wondering "did that just work?" seeing the config diff or at least "config has changed" will do the trick 💯

PS: while my expertise is predominantly JS-based, I'm happy to hack my way thru this enhancement, likely with a bit of guidance 😊

What do we all think? 🤔

Hey all, this is my first issue here so please take it easy on me 😅 ## Issue This caught me by surprise as the docs do not mention how to deal with config-only changes, but [talk about managing secrets](https://docs.coopcloud.tech/operators/handbook/#managing-secret-data). I automatically assumed that config would be treated the same as secrets: change it, and deploy 🙏 But `abra app deploy myapp.example.com` just says **there's nothing new to deploy** 💀 👉I found `--force -f` though and have been using that flag since, but it doesn't feel "right"? ## Expected behaviour My ideal DX (developer experience) would be: 1. Change config via `app config ..` 2. Deploy via `app deploy ..` 3. Be prompted with `.env` changes in summary _(ideally what vars changed, but just a mention of "config updates" suffices for now!)_ 4. Confirm deploy, which ships the new `.env` and simply restarts the service _(if that's the best way to do it?)_ This approach keeps the Dev aware of what they're doing & why the app is being deployed. It also gives peace of mind because you're always wondering "did that just work?" seeing the config diff or at least "config has changed" will do the trick 💯 _PS: while my expertise is predominantly JS-based, I'm happy to hack my way thru this enhancement, likely with a bit of guidance_ 😊 ### **What do we all think?** 🤔

❤️ 2

decentral1se commented

2025-11-02 09:52:15 +00:00

Thanks for raising @pharaohgraphy 👋

Be prompted with .env changes in summary (ideally what vars changed, but just a mention of "config updates" suffices for now!)

I have a feeling you might be referring to "config" as "env vars"? Docker swarm has the concept of configs on it's own and if these change, they are shown in the deployment overview since #657.

So, to summarise, and correct me if wrong:

Remove -f from abra app deploy
Have abra app deploy do what -f does and just re-deploy (credit also @p4u1)
Show what env vars are new/updated in the deployment overview / prompt moment

I think this seems doable. @3wordchant do you have some wisdom for this as the person who implemented the "show changes" functionality. I have a slight worry the overview get's too crowded but OTOH, we do not show things that don't change?

Confirm deploy, which ships the new .env and simply restarts the service (if that's the best way to do it?)

The docker swarm runtime will update the container/env/etc. for us, no restart required.

What do we all think?

Sounds like an very good idea, simplifying the CLI interface and increasing the amount of useful information that is shown on deploy overview. Thanks for bringing this up! New perspectives on the using the tool are very valuable 🙏 🫶

Thanks for raising @pharaohgraphy 👋 > Be prompted with .env changes in summary (ideally what vars changed, but just a mention of "config updates" suffices for now!) I have a feeling you might be referring to "config" as "env vars"? Docker swarm has the concept of configs on it's own and if these change, they are shown in the deployment overview since https://git.coopcloud.tech/toolshed/abra/pulls/657. So, to summarise, and correct me if wrong: * Remove `-f` from `abra app deploy` * Have `abra app deploy` do what `-f` does and just re-deploy (credit also @p4u1) * Show what env vars are new/updated in the deployment overview / prompt moment I think this seems doable. @3wordchant do you have some wisdom for this as the person who implemented the "show changes" functionality. I have a slight worry the overview get's too crowded but OTOH, we do not show things that don't change? > Confirm deploy, which ships the new .env and simply restarts the service (if that's the best way to do it?) The docker swarm runtime will update the container/env/etc. for us, no restart required. > What do we all think? Sounds like an very good idea, simplifying the CLI interface and increasing the amount of useful information that is shown on deploy overview. Thanks for bringing this up! New perspectives on the using the tool are very valuable 🙏 🫶

👍 1

decentral1se added the

enhancement

label 2025-11-02 09:53:17 +00:00

decentral1se changed title from ~~"app deploy" should work if config (.env) for the app has changed~~ to `abra app deploy` handles re-deploy and shows env updates

2025-11-02 09:53:56 +00:00

p4u1 commented

2025-11-04 19:07:54 +00:00

Remove -f from abra app deploy

While working on our automation, we realised that it would still be nice to have the -f flag for the case that no input changed but we still want tp redeploy.

Default behaviour:

only deploy when input changed, like app.env, compose.yml, configs, secrets...
With -f:
always deploy no matter what

This way we can run ´abra app deploy --no-input` in our automation and detect when no changes were detected and nothing had to be redeployed

> Remove -f from abra app deploy While working on our automation, we realised that it would still be nice to have the -f flag for the case that no input changed but we still want tp redeploy. Default behaviour: - only deploy when input changed, like app.env, compose.yml, configs, secrets... With `-f`: - always deploy no matter what This way we can run ´abra app deploy --no-input` in our automation and detect when no changes were detected and nothing had to be redeployed

👍 1

pharaohgraphy commented

2025-11-04 23:13:54 +00:00

@decentral1se you're correct, the confusion stems from the fact that Abra calls it config but Docker is just injecting Env vars... not sure it's worth renaming, it would be a breaking change 🤷

@p4u1 I agree, we should keep -f it's a useful escape-hatch in general.

I will note this though, I've noticed more than just a couple times that mutating an env var via abra app config ... then running a forced deploy can often ADD the env var with the new value to the Docker service, but it DOES NOT remove the old one..

I had to go on the server itself a few times to manually do: docker service ... --env-rm "MY_ENV" then re-add it manually via docker service ... --env-add ...

I want to flag this now, because I have a feeling this will become an issue if we don't address it properly, I'm unsure how Abra does most things under the hood, so forgive me for potentially missing important context on this. 😅

FWIW: This has been a hindrance for testing new apps and more importantly for hacking away at recipes, it has slowed down my productivity significantly enough to be an issue

@decentral1se you're correct, the confusion stems from the fact that Abra calls it `config` but Docker is just injecting Env vars... not sure it's worth renaming, it would be a breaking change 🤷 @p4u1 I agree, we should keep `-f` it's a useful escape-hatch in general. I will note this though, I've noticed more than just a couple times that mutating an env var via `abra app config ...` then running a forced deploy can often ADD the env var with the new value to the Docker service, but it DOES NOT remove the old one.. I had to go on the server itself a few times to manually do: `docker service ... --env-rm "MY_ENV"` then re-add it manually via `docker service ... --env-add ...` I want to flag this now, because I have a feeling this will become an issue if we don't address it properly, I'm unsure how Abra does most things under the hood, so forgive me for potentially missing *important context* on this. 😅 _FWIW: This has been a hindrance for testing new apps and more importantly for hacking away at recipes, it has slowed down my productivity significantly enough to be an issue_

decentral1se referenced this issue

2025-11-04 23:20:01 +00:00

`abra app config` -> `abra app env edit` #722

decentral1se commented

2025-11-04 23:46:56 +00:00

I will note this though, I've noticed more than just a couple times that mutating an env var via abra app config ... then running a forced deploy can often ADD the env var with the new value to the Docker service, but it DOES NOT remove the old one..

That's true, we just append and don't care what is already added on:

		pkg/app/app.go
		Lines 504 to 528 in c3a2048eba
	
				// ExposeAllEnv exposes all env variables to the app container

				func ExposeAllEnv(

					stackName string,

					compose *composetypes.Config,

					appEnv envfile.AppEnv,

					toDeployVersion string) {

					for _, service := range compose.Services {

						if service.Name == "app" {

							log.Debug(i18n.G("adding env vars to %s service config", stackName))

							for k, v := range appEnv {

								_, exists := service.Environment[k]

								if !exists {

									value := v

									if k == "TYPE" || k == "RECIPE" {

										// NOTE(d1): don't use the wrong version from the app env

										//           since we are deploying a new version

										value = toDeployVersion

									}

									service.Environment[k] = &value

									log.Debug(i18n.G("%s: %s: %s", stackName, k, value))

								}

							}

						}

					}

				}

We don't fully control the values that go to .Config.Env AFAIU since the Dockerfile or compose.yml might specify additional env vars that abra won't gather from the .env file... so removing stuff might break something else... do you see a way to resolve this?

> I will note this though, I've noticed more than just a couple times that mutating an env var via abra app config ... then running a forced deploy can often ADD the env var with the new value to the Docker service, but it DOES NOT remove the old one.. That's true, we just append and don't care what is already added on: https://git.coopcloud.tech/toolshed/abra/src/commit/c3a2048eba010a30afada889cc44d75a61ebf5ee/pkg/app/app.go#L504-L528 We don't fully control the values that go to `.Config.Env` AFAIU since the `Dockerfile` or `compose.yml` might specify additional env vars that `abra` won't gather from the `.env` file... so removing stuff might break something else... do you see a way to resolve this?

decentral1se commented

2025-11-04 23:50:28 +00:00

This way we can run ´abra app deploy --no-input` in our automation and detect when no changes were detected and nothing had to be redeployed

@p4u1 would you parse the output or should we be adding a -m output for abra app deploy? Trying to satisfy Ansible with output parsing that might change through different versions might be a recipe for pain. It might make sense to break out a separate issue for idempotency in abra for automation tools 🤔

> This way we can run ´abra app deploy --no-input` in our automation and detect when no changes were detected and nothing had to be redeployed @p4u1 would you parse the output or should we be adding a `-m` output for `abra app deploy`? Trying to satisfy Ansible with output parsing that might change through different versions might be a recipe for pain. It might make sense to break out a separate issue for idempotency in `abra` for automation tools 🤔

pharaohgraphy commented

2025-11-04 23:58:19 +00:00

@decentral1se My 2c is Abra should be 'smarter' about this rather than gung-ho, here's what I envision SHOULD work based on what I've tried manually in the server's CLI via docker service .. commands:

Dev runs: abra app env ... and updates the env file locally then saves it
Dev runs: abra app deploy ...
Abra runs: a diff between local .env and server's .env, it finds the names of the vars that have been mutated
Abra runs: docker service ... --env-rm ... for all the env vars that have mutated
Abra runs: docker service ... --env-add ... for all the new values of the env vars mutated

This ensures we don't destroy env vars injected outside of Abra, this is how I've done it manually and it seems to work just fine for all the apps that I've tried. 🤷

@decentral1se My 2c is Abra should be 'smarter' about this rather than gung-ho, here's what I envision SHOULD work based on what I've tried manually in the server's CLI via `docker service ..` commands: 1. Dev runs: `abra app env ...` and updates the env file locally then saves it 2. Dev runs: `abra app deploy ...` 3. Abra runs: a diff between local `.env` and server's `.env`, it finds the names of the vars that have been mutated 4. Abra runs: `docker service ... --env-rm ...` for all the env vars that have mutated 5. Abra runs: `docker service ... --env-add ...` for all the new values of the env vars mutated This ensures we don't destroy env vars injected outside of Abra, this is how I've done it manually and it seems to work just fine for all the apps that I've tried. 🤷

👍 2

decentral1se referenced this issue

2025-11-05 00:07:44 +00:00

Ensure `.Config.Env` overwrites existing env vars on update #723

decentral1se added this to the Abra "next" project 2025-11-05 00:36:53 +00:00

Sign in to join this conversation.