docs: document plugin properties migrated from env vars

Per-plugin management docs now describe the properties introduced by the env-var-to-property migration in PR #8498, and stale prose and command-output examples that still referenced the old `DOKKU_*` names have been refreshed. The deprecated env vars table moves out of `environment-variables.md` and into the 0.38.0 migration guide, where it functions as a one-time pointer for upgrading users rather than ongoing reference material.

docs/deployment/application-management.md

@@ -13,6 +13,7 @@ apps:lock <app>                                # Locks an app for deployment
 apps:locked <app>                              # Checks if an app is locked for deployment
 apps:rename <old-app> <new-app>                # Rename an app
 apps:report [<app>] [<flag>]                   # Display report about an app
+apps:set [--global] <app> <key> (<value>)      # Set or clear an apps property for an app
 apps:unlock <app>                              # Unlocks an app for deployment
 ```
 
@@ -78,6 +79,20 @@ Once created, you can configure the application as normal, and deploy the applic
 - Create and link datastores.
 - Set environment variables.
 
+### Disabling automatic app creation
+
+By default, pushing to a git remote for an app that does not yet exist on the Dokku host will cause the app to be created automatically. On shared or production hosts this may be undesirable - operators may prefer that an explicit `apps:create` is required first. The `disable-autocreation` global property controls this behavior:
+
+```shell
+dokku apps:set --global disable-autocreation true
+```
+
+While set, pushes targeting an app that does not exist will be rejected. The default behavior may be restored by passing an empty value:
+
+```shell
+dokku apps:set --global disable-autocreation
+```
+
 ### Removing a deployed app
 
 In some cases, you may need to destroy an application, whether it is because the application is temporary or because it was misconfigured. In these cases, you can use the `apps:destroy` command. Performing any destructive actions in Dokku requires confirmation, and this command will ask for the name of the application being deleted before doing so.

docs/deployment/builders/builder-management.md

@@ -82,6 +82,28 @@ The default value may be set by passing an empty value for the option.
 dokku builder:set --global build-dir
 ```
 
+#### Skipping container and image cleanup
+
+After a successful deploy, Dokku removes old containers and images that are no longer referenced by the app. On hosts where image rebuilds are expensive or where operators want to retain prior images for manual rollback, this cleanup can be disabled per-app or globally via the `skip-cleanup` property:
+
+```shell
+dokku builder:set node-js-app skip-cleanup true
+```
+
+The property can also be set globally:
+
+```shell
+dokku builder:set --global skip-cleanup true
+```
+
+The default behavior (cleanup enabled) may be restored by passing an empty value:
+
+```shell
+dokku builder:set node-js-app skip-cleanup
+```
+
+For backwards compatibility with bootstrap-time configuration, the `DOKKU_SKIP_CLEANUP` environment variable in `/etc/environment` or `~dokku/.dokkurc/*` is still honored when the `skip-cleanup` property is unset. The property is the canonical interface and takes precedence when set.
+
 ### Displaying builder reports for an app
 
 You can get a report about the app's builder status using the `builder:report` command:

docs/deployment/builders/dockerfiles.md

@@ -185,7 +185,7 @@ You would adjust the cache directory for whatever application cache you have, e.
 
 ### Customizing the run command
 
-By default no arguments are passed to `docker run` when deploying the container and the `CMD` or `ENTRYPOINT` defined in the `Dockerfile` are executed. You can take advantage of docker ability of overriding the `CMD` or passing parameters to your `ENTRYPOINT` setting `$DOKKU_DOCKERFILE_START_CMD`. Let's say for example you are deploying a base Node.js image, with the following `ENTRYPOINT`:
+By default no arguments are passed to `docker run` when deploying the container and the `CMD` or `ENTRYPOINT` defined in the `Dockerfile` are executed. You can take advantage of docker's ability to override the `CMD` or pass parameters to your `ENTRYPOINT` by setting the `dockerfile-start-cmd` property on the `ps` plugin. Let's say for example you are deploying a base Node.js image, with the following `ENTRYPOINT`:
 
 ```Dockerfile
 ENTRYPOINT ["node"]
@@ -194,10 +194,14 @@ ENTRYPOINT ["node"]
 You can do:
 
 ```shell
-dokku config:set node-js-app DOKKU_DOCKERFILE_START_CMD="--harmony server.js"
+dokku ps:set node-js-app dockerfile-start-cmd "--harmony server.js"
 ```
 
-To tell Docker what to run.
+To tell Docker what to run. Pass an empty value to clear the override:
+
+```shell
+dokku ps:set node-js-app dockerfile-start-cmd
+```
 
 ### Procfiles and multiple processes
 

docs/deployment/schedulers/scheduler-management.md

@@ -45,6 +45,26 @@ The default value may be set by passing an empty value for the option.
 dokku scheduler:set --global selected
 ```
 
+### Setting the app shell
+
+The shell used for `dokku run` and `dokku enter` invocations against an app can be customized via the `shell` property. This is useful for images that ship with a non-default shell - for example, alpine-based images that only have `/bin/sh`.
+
+```shell
+dokku scheduler:set node-js-app shell sh
+```
+
+The `shell` property can also be set globally:
+
+```shell
+dokku scheduler:set --global shell sh
+```
+
+The default value (an empty string, which lets the scheduler pick its own default) may be restored by passing an empty value:
+
+```shell
+dokku scheduler:set node-js-app shell
+```
+
 ### Displaying scheduler reports for an app
 
 You can get a report about the app's scheduler status using the `scheduler:report` command:

docs/deployment/zero-downtime-deploys.md

@@ -67,10 +67,6 @@ dokku checks:skip node-js-app worker,web
 
 ```
 -----> Skipping zero downtime for app's (node-js-app) proctypes (worker,web)
------> Unsetting node-js-app
------> Unsetting DOKKU_CHECKS_DISABLED
------> Setting config vars
-       DOKKU_CHECKS_SKIPPED: worker,web
 ```
 
 Zero downtime checks can also be disabled completely. This will stop old containers *before* new ones start, which may result in broken connections and downtime if your application fails to boot properly.
@@ -81,10 +77,6 @@ dokku checks:disable node-js-app worker
 
 ```
 -----> Disabling zero downtime for app's (node-js-app) proctypes (worker)
------> Setting config vars
-       DOKKU_CHECKS_DISABLED: worker
------> Setting config vars
-       DOKKU_CHECKS_SKIPPED: web
 ```
 
 ### Displaying checks reports for an app