michiels
commented
5 years ago I think the basics for this feature are now implemented in #254 and #256. A good suggestion by @joshuajansen was to add a real attribute to an EnvVar record like "applied_at` or something like that. This way we could keep track of which env vars modified are already applied to the app or not and indicate that on the Env var management page.
The only thing there is that when removing env vars we wouldn't have that status indicator as the model record would already be gone. We could add some "removed" indicator to an EnvVar record and only when that's applied, fully remove it from the Env var management screen.
I think this is material for a new feature and issue.
Problem
When you add an ENV var via the Intercity UI, we instantly kick off an SSH command to add the ENV var to the app. This is all working fine.
Until you add multiple ENV vars in quick order: that will kick off multiple SSH commands to the Dokku server in under a minute. This messes up the Dokku rolling-restart, container renaming and container killing mechanism. Leaving you with dangling running containers.
This is especially a problem when you have Sidekiq workers running: you'll be left with old versions of Sidekiq works since they're not properly cleaned up.
This would also "fix" #167 in part as you will be able to quickly remove and re-add the same ENV var with a different value.
Suggestion
Dokku offers an option when adding an ENV var, to not restart/redeploy the app right away. We could add a checkbox in Intercity to set this option when adding an ENV var. This allows you to add multiple ENV vars without restarting the app yet, and then on the last ENV var restart it.
On top of this, we could also add a more generic "restart/redeploy" button so that you can always trigger configuration changes when you've made them in batch.