[CT-1737] Support all "global" flags after all subcommands

[jtcohen6]

See comment below for updated proposal

We currently distinguish between two types of flags:

• those which precede the subcommand ("global"), e.g. --no-use-color
• those which follow the subcommand, and may have different behavior depending on the subcommand, e.g. --select, --full-refresh

IMO this is pretty confusing for end users! We should really seek to support flags in any order (and resolve any resulting ambiguities by actually renaming flags). I know we implemented the new CLI modeling in accordance with the old CLI model — parity is a good goal to shoot for with any refactor — but it would be great to just support both of these, seamlessly and equivalently:

$ dbt --no-use-color run --select one_model
$ dbt run --select one_model --no-use-color

[iknox-fa]

Per BLG on 1/17/23 converting to a spike.. this is a lot of work and has a lot of potential pitfalls.

[github-actions]

This issue has been marked as Stale because it has been open for 180 days with no activity. If you would like the issue to remain open, please comment on the issue or else it will be closed in 7 days.

[jtcohen6]

One way to accomplish this goal: all global/root parameters should also be defined on every single subcommand, so that you can pass them before or after that subcommand.

Considerations:

• We already have some logic that raises an error if you try to pass it in both places: dbt --fail-fast run --no-fail-fast
• We would want to ensure complete coverage going forward: do this programmatically (”global” decorator-of-decorators?), or have a test to ensure that every relevant param is shared across both sets

Without being too clever, I think this could be a reasonable way to go for now.

Then, we should update our documentation to encourage that users always pass flags after the subcommand.

[graciegoheen]

From refinement meeting:

• would we want to deprecate the global parameters in the future? maybe! when we do, we'll add deprecation warnings before doing so
• will need a documentation update
• update old tests, write new tests
• for click, you have to inject the flag in, not as easy to just add extra flags in

[aranke]

@jtcohen6 What's the expected behavior in the following scenarios:

1. A flag is present at global and sub-command levels, but has the same value at each level?
2. A flag is present at global and sub-command levels, but has different values at each level?

[jtcohen6]

@aranke Current state (since v1.5) is that we raise an error in both cases. I think we should preserve that behavior.

dbt-core/core/dbt/cli/flags.py

Lines 97 to 105 in d597b80

	# Ensure that any params sourced from the commandline are not present more than once.
	# Click handles this exclusivity, but only at a per-subcommand level.
	seen_params = []
	for param in _get_params_by_source(ctx, ParameterSource.COMMANDLINE):
	if param in seen_params:
	raise DbtUsageException(
	f"{param.lower()} was provided both before and after the subcommand, it can only be set either before or after.",
	)
	seen_params.append(param)

(Implemented in #7303)