docs: update markdownlint rules for better formatting

docs/deployment/application-deployment.md

@@ -102,7 +102,7 @@ Once the deploy is complete, the application's web URL will be generated as abov
 Dokku supports deploying applications in a few ways:
 
 - [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) via [Herokuish](https://github.com/gliderlabs/herokuish#buildpacks): See the [herokuish buildpacks documentation](/docs/deployment/builders/herokuish-buildpacks.md) to learn about the different ways to specify a buildpack.
-  - This is the default method used by Dokku.
+    - This is the default method used by Dokku.
 - [Dockerfile](https://docs.docker.com/reference/builder/): See the [dockerfile documentation](/docs/deployment/builders/dockerfiles.md) to learn about the different ways to configure Dockerfile-based deploys.
 - [Docker Image](https://docs.docker.com/get-started/overview/#docker-objects): See the [docker image documentation](/docs/deployment/methods/git.md#initializing-an-app-repository-from-a-docker-image) to learn about how to deploy a Docker Image.
 
@@ -148,7 +148,7 @@ dokku config:set ruby-getting-started DOKKU_SKIP_DEPLOY=true
 
 ### Redeploying or restarting
 
-If you need to redeploy or restart your app: 
+If you need to redeploy or restart your app:
 
 ```shell
 # on the Dokku host

docs/deployment/builders/builder-management.md

@@ -131,14 +131,14 @@ dokku builder:report node-js-app --builder-selected
 To create a custom builder, the following triggers must be implemented:
 
 - `builder-build`:
-  - arguments: `BUILDER_TYPE` `APP` `SOURCECODE_WORK_DIR`
-  - description: Creates a docker image named with the output of `common#get_app_image_name $APP`.
+    - arguments: `BUILDER_TYPE` `APP` `SOURCECODE_WORK_DIR`
+    - description: Creates a docker image named with the output of `common#get_app_image_name $APP`.
 - `builder-detect`:
-  - arguments: `APP` `SOURCECODE_WORK_DIR`
-  - description: Outputs the name of the builder (without the `builder-` prefix) to use to build the app.
+    - arguments: `APP` `SOURCECODE_WORK_DIR`
+    - description: Outputs the name of the builder (without the `builder-` prefix) to use to build the app.
 - `builder-release`:
-  - arguments: `BUILDER_TYPE` `APP` `IMAGE_AG`
-  - description: A post-build, pre-release trigger that can be used to post-process the image. Usually simply tags and labels the image appropriately.
+    - arguments: `BUILDER_TYPE` `APP` `IMAGE_AG`
+    - description: A post-build, pre-release trigger that can be used to post-process the image. Usually simply tags and labels the image appropriately.
 
 Custom plugins names _must_ have the prefix `builder-` or builder overriding via `builder:set` may not function as expected.
 

docs/deployment/builders/cloud-native-buildpacks.md

@@ -28,25 +28,27 @@ Builds will proceed with the `pack` cli for the app from then on.
 As this functionality is highly experimental, there are a number of caveats. Please note that not all issuesare listed below.
 
 - Specifying specific buildpacks is not currently possible.
-  - A future release will add support for specifying buildpacks via the `buildpacks` plugin.
+    - A future release will add support for specifying buildpacks via the `buildpacks` plugin.
 - There is currently no way to specify extra arguments for `pack` cli invocations.
-  - A future release will add support for injecting extra arguments during the build process.
+    - A future release will add support for injecting extra arguments during the build process.
 - The default process type is `web`.
 - Build cache is stored in Docker volumes instead of on disk. As such, `repo:purge-cache` currently has no effect.
-  - A future version will add integration with the `repo` plugin.
+    - A future version will add integration with the `repo` plugin.
 - `pack` is not currently included with Dokku, nor is it added as a package dependency.
-  - A future version will include it as a package dependency.
+    - A future version will include it as a package dependency.
 
 ### Detection
 
 This builder will be auto-detected in either the following cases:
 
 - The `DOKKU_CNB_EXPERIMENTAL` app environment variable is set to `1`.
-  ```shell
-  dokku config:set --no-restart node-js-app DOKKU_CNB_EXPERIMENTAL=1
-  ```
+
+    ```shell
+    dokku config:set --no-restart node-js-app DOKKU_CNB_EXPERIMENTAL=1
+    ```
+
 - A `project.toml` file exists in the root of the app repository.
-  - This file is consumed by `pack-cli` and used to describe how the app is built.
+    - This file is consumed by `pack-cli` and used to describe how the app is built.
 
 The builder can also be specified via the `builder:set` command:
 

docs/deployment/builders/herokuish-buildpacks.md

@@ -22,9 +22,9 @@ builder-herokuish:set <app> <key> (<value>) # Set or clear a builder-herokuish p
 Dokku normally defaults to using [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) for deployment, though this may be overridden by committing a valid `Dockerfile` to the root of your repository and pushing the repository to your Dokku installation. To avoid this automatic `Dockerfile` deployment detection, you may do one of the following:
 
 - Set a `BUILDPACK_URL` environment variable
-  - This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
+    - This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
 - Create a `.buildpacks` file in the root of your repository.
-  - This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
+    - This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
 
 This page will cover usage of the `buildpacks` plugin.
 
@@ -35,9 +35,9 @@ This page will cover usage of the `buildpacks` plugin.
 This builder will be auto-detected in either the following cases:
 
 - The `BUILDPACK_URL` app environment variable is set.
-  - This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
+    - This can be done via `dokku config:set` or via a committed `.env` file in the root of the repository. See the [environment variable documentation](/docs/configuration/environment-variables.md) for more details.
 - A `.buildpacks` file exists in the root of the app repository.
-  - This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
+    - This can be via a committed `.buildpacks` file or managed via the `buildpacks` plugin commands.
 
 The builder can also be specified via the `builder:set` command:
 

docs/deployment/methods/git.md

@@ -38,7 +38,7 @@ When an application is created via `git push`, Dokku will create the proper `pre
 dokku git:initialize node-js-app
 ```
 
-In order for the above command to succeed, the application _must_ already exist. 
+In order for the above command to succeed, the application _must_ already exist.
 
 > Warning: If the `pre-receive` hook was customized in any way, this will overwrite that hook with the current defaults for Dokku.
 

docs/deployment/remote-commands.md

@@ -91,7 +91,7 @@ In addition, the following commands have special local side-effects:
 
 #### Specifying a remote
 
-While many users will only ever push to a single dokku remote from a given repository, it may be useful to point the same repository at multiple remotes, especially in the case of pre-production environments. This can be done via the `remote` commands. These commands are _only_ available within the official remote client, and are not server-side commands.
+While many users will only ever push to a single dokku remote from a given repository, it may be useful to point the same repository at multiple remotes, especially in the case of pre-production environments. This can be done via the `remote` commands. These commands are *only* available within the official remote client, and are not server-side commands.
 
 To see your currently configured remote, run `dokku remote`. This will respect the `--remote` flag.
 
@@ -101,7 +101,7 @@ To add a remote, run `dokku remote:add $REMOTE_NAME dokku@dokku.me:$APP_NAME`, r
 
 To remove a remote, run `dokku remote:remove $REMOTE_NAME`. This is equivalent to running `git remote remove $REMOTE_NAME`.
 
-By default, the remote in use is `dokku`. To change the remote the client uses by default, run `dokku remote:set $REMOTE_NAME`, where `$REMOTE_NAME` is the name of your desired remote. This will not check the value specified, so that remote _must_ be available or errors will occur when running normal client commands. Note that specifying `--remote` when running dokku commands will override this configuration value.
+By default, the remote in use is `dokku`. To change the remote the client uses by default, run `dokku remote:set $REMOTE_NAME`, where `$REMOTE_NAME` is the name of your desired remote. This will not check the value specified, so that remote *must* be available or errors will occur when running normal client commands. Note that specifying `--remote` when running dokku commands will override this configuration value.
 
 To clear the configured remote, run `dokku remote:unset`. The client will unset the configured remote, and will default back to `dokku`, or the value of `--remote` if specified.
 

docs/deployment/schedulers/docker-local.md

@@ -121,7 +121,6 @@ This plugin implements various functionality through `plugn` triggers to integra
 - `ps:stop`
 - `run`
 
-
 ### Logging support
 
 App logs for the `logs` command are fetched from running containers via the `docker` cli. To persist logs across deployments, consider using Dokku's [vector integration](/docs/deployment/logs.md#vector-logging-shipping) to ship logs to another service or a third-party platform.
@@ -133,15 +132,15 @@ The `docker-local` scheduler supports a minimal list of resource _limits_ and _r
 #### Resource Limits
 
 - cpu: (docker option: `--cpus`), is specified in number of CPUs a process can access.
-  - See the ["CPU" section](https://docs.docker.com/config/containers/resource_constraints/#cpu) of the Docker Runtime Options documentation for more information.
+    - See the ["CPU" section](https://docs.docker.com/config/containers/resource_constraints/#cpu) of the Docker Runtime Options documentation for more information.
 - memory: (docker option: `--memory`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes). Default unit is `m` (megabytes).
-  - See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
+    - See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
 - memory-swap: (docker option: `--memory-swap`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes)
-  - See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
+    - See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
 - nvidia-gpus: (docker option: `--gpus`), is specified in number of Nvidia GPUs a process can access.
-  - See the ["GPU" section](https://docs.docker.com/config/containers/resource_constraints/#gpu) of the Docker Runtime Options documentation for more information.
+    - See the ["GPU" section](https://docs.docker.com/config/containers/resource_constraints/#gpu) of the Docker Runtime Options documentation for more information.
 
 #### Resource Reservations
 
 - memory: (docker option: `--memory-reservation`) should be specified with a suffix of `b` (bytes), `k` (kilobytes), `m` (megabytes), `g` (gigabytes). Default unit is `m` (megabytes).
-  - See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.
+    - See the ["Memory" section](https://docs.docker.com/config/containers/resource_constraints/#memory) of the Docker Runtime Options documentation for more information.

docs/deployment/schedulers/scheduler-management.md

@@ -91,23 +91,23 @@ Custom plugins names _must_ have the prefix `scheduler-` or scheduler overriding
 At this time, the following dokku commands are used to implement a complete scheduler.
 
 - `apps:destroy`: stops the app processes on the scheduler
-  - triggers: post-delete, scheduler-register-retired, scheduler-retire
+    - triggers: post-delete, scheduler-register-retired, scheduler-retire
 - `apps:rename`: handles app renaming
-  - triggers: post-app-rename-setup
+    - triggers: post-app-rename-setup
 - `apps:clone`: handles app cloning
-  - triggers: post-app-clone-setup
+    - triggers: post-app-clone-setup
 - `deploy`: deploys app proceses and checks the status of a deploy
-  - triggers: scheduler-app-status, scheduler-deploy, scheduler-is-deployed, scheduler-logs-failed
+    - triggers: scheduler-app-status, scheduler-deploy, scheduler-is-deployed, scheduler-logs-failed
 - `enter`: enters a running container
-  - triggers: scheduler-enter
+    - triggers: scheduler-enter
 - `logs`: fetches app logs
-  - triggers: scheduler-logs
+    - triggers: scheduler-logs
 - `run`: starts one-off run containers (detached and non-detached) as well as listing run processes
-  - triggers: scheduler-run, scheduler-run-list
+    - triggers: scheduler-run, scheduler-run-list
 - `ps:stop`: stops app processes
-  - triggers: scheduler-stop
+    - triggers: scheduler-stop
 - `ps:inspect`: outputs inspect output for processes in an app
-  - triggers: scheduler-inspect
+    - triggers: scheduler-inspect
 
 Schedulers may decide to omit some functionality here, or use plugin triggers to supplement config with information from other plugins. Additionally, a scheduler may implement other triggers in order handle any extra processes needed during a deploy.
 

docs/deployment/user-management.md

@@ -82,7 +82,6 @@ echo "$CONTENTS_OF_YOUR_PUBLIC_SSH_KEY_HERE" | dokku ssh-keys:add KEY_NAME
 SHA256:ABC123ABC123+abc123abc123Zabc123abcZ123abc
 ```
 
-
 ```shell
 cat path/to/id_rsa.pub | dokku ssh-keys:add KEY_NAME
 ```
@@ -91,7 +90,6 @@ cat path/to/id_rsa.pub | dokku ssh-keys:add KEY_NAME
 SHA256:ABC123ABC123+abc123abc123Zabc123abcZ123abc
 ```
 
-
 Admin users and root can add keys remotely by specifying the `dokku` bin on their `ssh` command:
 
 ```shell

docs/deployment/zero-downtime-deploys.md

@@ -163,12 +163,12 @@ A healthcheck entry takes the following properties:
 - `attempts`: (default: `3` seconds) Number of retry attempts to perform on failure.
 - `command`: (default `''` - empty string) Command to execute within container.
 - `content`: (default: `''` - empty string) Content to search in http path check output.
-initialDelay	default: 0, unit: seconds) Number of seconds to wait after a container has started before triggering the healthcheck.
+- `initialDelay`: (default: 0, unit: seconds) Number of seconds to wait after a container has started before triggering the healthcheck.
 - `name`: (default: autogenerated) The name of the healthcheck. If unspecified, it will be autogenerated from the rest of the healthcheck information.
 - `path`: (default: `/` - for http checks): An http path to check.
 - `timeout`: (default: `5` seconds): Number of seconds to wait before timing out a healthcheck.
 - `type`: (default: `""` - none): Type of the healthcheck. Options: liveness, readiness, startup.
-- `uptime`: (default: `""` - none): Amount of time the container must be alive before the container is considered healthy. Any restarts will cause this to check to fail, and this check does not respect retries.	
+- `uptime`: (default: `""` - none): Amount of time the container must be alive before the container is considered healthy. Any restarts will cause this to check to fail, and this check does not respect retries.
 - `wait`: (default: `5` seconds): Number of seconds to wait between healthcheck attempts.
 
 > Warning: Healthchecks are implemented by specific scheduler plugins, and not all plugins support all options. Please consult the scheduler documentation for further details on what is supported.