Confusion around argument/flag order

Summary

The fact that "Global" options need to come before the command is not intuitive, easy to miss in the docs and unlike any other CLI I've used before.

Steps to reproduce

1. Be in a situation where you need to specify 1 or more global params e.g. --server
2. Miss in the docs (and not see an example) whereby you need to specify this argument before the create command
3. Run something like the below and watch it fail with the default help msg

release-cli create \
--server-url https://gitlab.com \
--job-token ${CI_JOB_TOKEN} \
--project-id ${CI_PROJECT_ID} \
--name test-release-$CI_JOB_ID \
--description release-$CI_COMMIT_REF_NAME-$CI_JOB_ID \
--tag-name tag-$CI_JOB_ID \
--ref $CI_COMMIT_SHA \
--assets-link '{"name":"version.yaml","url":"${PACKAGE_REGISTRY_URL}/version.yaml"}' \
--milestone "${PACKAGE_VERSION}"

NAME:
release-cli - A CLI tool that interacts with GitLab's Releases API
USAGE:
help [global options] command [command options] [arguments...]
VERSION:
0.9.0
DESCRIPTION:

CLI tool that interacts with GitLab's Releases API https://docs.gitlab.com/ee/api/releases/.
All configuration flags will default to GitLab's CI predefined environment variables (https://docs.gitlab.com/ee/ci/variables/predefined_variables.html).
To override these values, use the [GLOBAL OPTIONS].
Get started with release-cli https://gitlab.com/gitlab-org/release-cli.
AUTHOR:
GitLab Inc. <support@gitlab.com>
COMMANDS:
create Create a Release using GitLab's Releases API https://docs.gitlab.com/ee/api/releases/#create-a-release
get Get a Release by tag name using GitLab's Releases API https://docs.gitlab.com/ee/api/releases/index.html#get-a-release-by-a-tag-name
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--server-url value The base URL of the GitLab instance, including protocol and port, for example https://gitlab.example.com:8080 [$CI_SERVER_URL]
--job-token value Job token used for authenticating with the GitLab Releases API (default: ) [$CI_JOB_TOKEN]
--project-id value The current project's unique ID; used by GitLab CI internally [$CI_PROJECT_ID]
--timeout value HTTP client's timeout in Go's duration format https://golang.org/pkg/time/#ParseDuration (default: 30s) [$RELEASE_CLI_TIMEOUT]
--private-token value Private token used for authenticating with the GitLab Releases API, requires api scope https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html, overrides job-token (default: ) [$GITLAB_PRIVATE_TOKEN]
--additional-ca-cert-bundle value Configure a custom SSL CA certificate authority, can be a path to file or the content of the certificate [$ADDITIONAL_CA_CERT_BUNDLE]
--insecure-https Set to true if you want to skip the client verifying the server's certificate chain and host name (default: false) [$INSECURE_HTTPS]
--help, -h Show help (default: false)
--version, -v Print the version (default: false)
time="2021-08-23T15:17:51Z" level=fatal msg="run app" cli=release-cli error="Required flags \"server-url, project-id\" not set" version=0.9.0

Example Project

n/a

What is the current bug behavior?

Displays default help message with error at the end saying the flags are not specified when they were passed after the create arg.

What is the expected correct behaviour?

Some or all of:

• Accept the flags in any order
• Better error msg, suggesting the ordering requirement
• An example in the docs showing the ordering e.g.

release-cli \
--server-url https://gitlab.com \
--job-token ${CI_JOB_TOKEN} \
--project-id ${CI_PROJECT_ID} \
create \
--name test-release-$CI_JOB_ID \
--description release-$CI_COMMIT_REF_NAME-$CI_JOB_ID \
--tag-name tag-$CI_JOB_ID \
--ref $CI_COMMIT_SHA \
--assets-link '{"name":"version.yaml","url":"${PACKAGE_REGISTRY_URL}/version.yaml"}' \
--milestone "${PACKAGE_VERSION}"

Relevant logs and/or screenshots

n/a

Output of checks

n/a

Possible fixes

See above suggestions.