feat(configuration): add initial support for Viper command initialization

[brandtkeller]

Description

Adds initial command support for viper configuration integrated with commands for initializing viper and detecting configuration file and environment variables.

Related Issue

Resolves #596

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Schema Updates applied
• Contributor Guide Steps followed

[meganwolf0]

There is a PersistentPreRun in many of the commands that override the rootCmd version -> specifically the dev ones, I see the viper config enabled there but due to this it doesn't seem to be reading the config data. Locally I removed PersistentPreRun from each of the dev commands and updated the parent devCmd as follows:

var devCmd = &cobra.Command{
	Use:   "dev",
	Short: "Collection of dev commands to make dev life easier",
	PersistentPreRun: func(cmd *cobra.Command, args []string) {
		// Call the parent's PersistentPreRun
		if parentPreRun := cmd.Parent().PersistentPreRun; parentPreRun != nil {
			parentPreRun(cmd.Parent(), args)
		}
		config.SkipLogFile = true
	},
}

I think this should solve it - the tools cmds also have this prerun, not sure if we want to update those as well/what the intended config recognition is there

(edit - happy to commit that fix ^^ if you agree, but refrained if there's more discussion needed, I might be missing something as well)

[brandtkeller]

@meganwolf0 ended up coming full circle with a slight modification of your proposed solution.

Optimally I wanted to have the inheritance of the PersistentPreRun as much as possible - which does function when you change the child commands to from PersistentPreRun to PreRun. Problem here then become the sequence of operations -> root would call SetupCLI() which logged it's use of a log file before the child/grandchild commands switched the logging file off.

Given we don't have much complexity baked into our command pre-runs this seems adequate for solving the problem on the two dev and tools commands. If we ever define the need we can simply move the PersistentPreRun down one level and re-think sequence.