cf help output returns in a random order #730
Description
Currently the output of a cf help <COMMAND> invocation returns in a random order. For example:
$: cf help push
NAME:
push - Push a new app or sync changes to an existing app
USAGE:
Push a single app (with or without a manifest):
cf push APP_NAME [-b BUILDPACK_NAME] [-c COMMAND] [-d DOMAIN] [-f MANIFEST_PATH] [--docker-image DOCKER_IMAGE]
[-i NUM_INSTANCES] [-k DISK] [-m MEMORY] [--hostname HOST] [-p PATH] [-s STACK] [-t TIMEOUT] [-u HEALTH_CHECK_TYPE] [--route-path ROUTE_PATH]
[--no-hostname] [--no-manifest] [--no-route] [--no-start]
Push multiple apps with a manifest:
cf push [-f MANIFEST_PATH]
ALIAS:
p
OPTIONS:
--hostname, -n Hostname (e.g. my-subdomain)
-d Domain (e.g. example.com)
-f Path to manifest
-t Maximum time (in seconds) for CLI to wait for application start, other server side timeouts may apply
--docker-image, -o docker-image to be used (e.g. user/docker-image-name)
--no-hostname Map the root domain to this app
--no-start Do not start an app after pushing
--route-path Path for the route
-b Custom buildpack by name (e.g. my-buildpack) or Git URL (e.g. 'https://github.com/cloudfoundry/java-buildpack.git') or Git URL with a branch or tag (e.g. 'https://github.com/cloudfoundry/java-buildpack.git#v3.3.0' for 'v3.3.0' tag). To use built-in buildpacks only, specify 'default' or 'null'
-c Startup command, set to null to reset to default start command
-m Memory limit (e.g. 256M, 1024M, 1G)
-p Path to app directory or to a zip file of the contents of the app directory
--health-check-type, -u Application health check type (e.g. port or none)
--no-route Do not map a route to this app and remove routes from previous pushes of this app.
-i Number of instances
-k Disk limit (e.g. 256M, 1024M, 1G)
--random-route Create a random route for this app
-s Stack to use (a stack is a pre-built file system, including an operating system, that can run apps)
--no-manifest Ignore manifest file
followed immediately by:
$: cf help push
NAME:
push - Push a new app or sync changes to an existing app
USAGE:
Push a single app (with or without a manifest):
cf push APP_NAME [-b BUILDPACK_NAME] [-c COMMAND] [-d DOMAIN] [-f MANIFEST_PATH] [--docker-image DOCKER_IMAGE]
[-i NUM_INSTANCES] [-k DISK] [-m MEMORY] [--hostname HOST] [-p PATH] [-s STACK] [-t TIMEOUT] [-u HEALTH_CHECK_TYPE] [--route-path ROUTE_PATH]
[--no-hostname] [--no-manifest] [--no-route] [--no-start]
Push multiple apps with a manifest:
cf push [-f MANIFEST_PATH]
ALIAS:
p
OPTIONS:
-p Path to app directory or to a zip file of the contents of the app directory
-s Stack to use (a stack is a pre-built file system, including an operating system, that can run apps)
--random-route Create a random route for this app
--route-path Path for the route
-b Custom buildpack by name (e.g. my-buildpack) or Git URL (e.g. 'https://github.com/cloudfoundry/java-buildpack.git') or Git URL with a branch or tag (e.g. 'https://github.com/cloudfoundry/java-buildpack.git#v3.3.0' for 'v3.3.0' tag). To use built-in buildpacks only, specify 'default' or 'null'
-m Memory limit (e.g. 256M, 1024M, 1G)
--hostname, -n Hostname (e.g. my-subdomain)
--docker-image, -o docker-image to be used (e.g. user/docker-image-name)
--no-route Do not map a route to this app and remove routes from previous pushes of this app.
-c Startup command, set to null to reset to default start command
-i Number of instances
-k Disk limit (e.g. 256M, 1024M, 1G)
-t Maximum time (in seconds) for CLI to wait for application start, other server side timeouts may apply
--health-check-type, -u Application health check type (e.g. port or none)
--no-hostname Map the root domain to this app
--no-manifest Ignore manifest file
--no-start Do not start an app after pushing
-d Domain (e.g. example.com)
-f Path to manifest
This makes it very difficult to reference or find help arguments when looking for something specific. The output should be in a deterministic order.