refactor: move DOKKU_WAIT_TO_RETIRE to a checks property

This centralizes the property and removes one more dokku-specific property from the app environment variables.

Closes #5049

docs/appendices/0.29.0-migration-guide.md

@@ -3,4 +3,8 @@
 ## Changes
 
 - The output of `run:detached` now uses the container name - eg. `node-js-app.run.1` - vs the container id.
-- The ID of `cron` tasks is now base36-encoded instead of base64-encoded.
+- The ID of `cron` tasks is now base36-encoded instead of base64-encoded.
+
+## Removals
+
+- The `DOKKU_WAIT_TO_RETIRE` environment variable has been migrated to a `checks` property named `wait-to-retire` and will be ignored if set as an environment variable.

docs/configuration/environment-variables.md

@@ -125,4 +125,3 @@ The following config variables have special meanings and can be set in a variety
 | `DOKKU_START_CMD`              | none                            | `dokku config:set`                                                                                                                               | Command to run instead of `/start $PROC_TYPE` |
 | `DOKKU_SYSTEM_GROUP`           | `dokku`                         | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*`                                                                           | System group to chown files as. |
 | `DOKKU_SYSTEM_USER`            | `dokku`                         | `/etc/environment` <br /> `~dokku/.dokkurc` <br /> `~dokku/.dokkurc/*`                                                                           | System user to chown files as. |
-| `DOKKU_WAIT_TO_RETIRE`         | `60`                            | `dokku config:set`                                                                                                                               | After a successful deploy, the grace period given to old containers before they are stopped/terminated. This is useful for ensuring completion of long-running http connections. |

docs/deployment/zero-downtime-deploys.md

@@ -22,13 +22,24 @@ You may both create user-defined checks for web processes using a `CHECKS` file,
 > - Allow checks from all hostnames: Modify your application to accept a dynamically provided hostname.
 > - Specify the domain within the check: See below for further documentation.
 
+## Configuring checks settings
+
+### wait-to-retire
+
+After a successful deploy, the grace period given to old containers before they are stopped/terminated is determined by the value of `wait-to-retire`. This is useful for ensuring completion of long-running HTTP connections.
+
+```shell
+dokku checks:set node-js-app wait-to-retire 30
+```
+
+Defaults to `60`.
+
 ## Configuring check settings using the `config` plugin
 
 There are certain settings that can be configured via environment variables:
 
 - `DOKKU_DEFAULT_CHECKS_WAIT`: (default: `10`) If no user-defined checks are specified - or if the process being checked is not a `web` process - this is the period of time Dokku will wait before checking that a container is still running.
 - `DOKKU_DOCKER_STOP_TIMEOUT`: (default: `10`) Configurable grace period given to the `docker stop` command. If a container has not stopped by this time, a `kill -9` signal or equivalent is sent in order to force-terminate the container. Both the `ps:stop` and `apps:destroy` commands *also* respect this value. If not specified, the Docker defaults for the [`docker stop` command](https://docs.docker.com/engine/reference/commandline/stop/) will be used.
-- `DOKKU_WAIT_TO_RETIRE`: (default: `60`) After a successful deploy, the grace period given to old containers before they are stopped/terminated. This is useful for ensuring completion of long-running HTTP connections.
 
 The following settings may also be specified in the `CHECKS` file, though are available as environment variables in order to ease application reuse.
 

docs/development/plugin-triggers.md

@@ -262,6 +262,22 @@ if [[ "$DOKKU_DISABLE_DEPLOY" = "true" ]]; then
 fi
 ```
 
+### `checks-get-property`
+
+- Description: Return the value for an app's checks property
+- Invoked by:
+- Arguments: `$APP $KEY`
+- Example:
+
+```shell
+#!/usr/bin/env bash
+
+set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
+APP="$1"; PROPERTY="$2"
+
+# TODO
+```
+
 ### `commands help` and `commands <PLUGIN_NAME>:help`
 
 - Description: Your plugin should implement a `help` command in your `commands` file to take advantage of this plugin trigger. `commands help` is used by `dokku help` to aggregate all plugins abbreviated `help` output. Implementing  `<PLUGIN_NAME>:help` in your `commands` file gives users looking for help, a more detailed output. 'commands help' must be implemented inside the `commands` plugin file. It's recommended that `PLUGIN_NAME:help` be added to the commands file to ensure consistency among community plugins and give you a new avenue to share rich help content with your user.
@@ -869,9 +885,9 @@ fi
 
 ### `logs-get-property`
 
-- Description: Fetches a given logs property value
+- Description: Return the value for an app's log property
 - Invoked by:
-- Arguments: `$APP` `$PROPERTY`
+- Arguments: `$APP $KEY`
 - Example:
 
 ```shell
@@ -990,7 +1006,7 @@ set -eo pipefail; [[ $DOKKU_TRACE ]] && set -x
 
 ### `network-get-property`
 
-- Description: Return the network value for an app's property
+- Description: Return the value for an app's network property
 - Invoked by: `internally triggered by a deploy`
 - Arguments: `$APP $KEY`
 - Example: