feat: config init

[markphelps]

Fixes: FLI-600
exploration to add a new command/subcommand:

» ./bin/flipt config init
? Configuration file path: /Users/markphelps/Library/Application Support/flipt/config.yml
» ./bin/flipt

    _________       __
   / ____/ (_)___  / /_
  / /_  / / / __ \/ __/
 / __/ / / / /_/ / /_
/_/   /_/_/ .___/\__/
         /_/

Version: dev
Commit: 02e90e36f4c74bd9b134ac377ebd06548f9640bf
Build Date: 2023-09-20T15:35:57Z
Go Version: go1.21.0
OS/Arch: darwin/arm64


API: http://0.0.0.0:8080/api/v1
UI: http://0.0.0.0:8080

^C2023-09-20T11:37:02-04:00	INFO	shutting down...
2023-09-20T11:37:02-04:00	INFO	shutting down HTTP server...	{"server": "http"}
2023-09-20T11:37:02-04:00	INFO	shutting down GRPC server...	{"server": "grpc"}

» ./bin/flipt config init
? Configuration file path: /Users/markphelps/Library/Application Support/flipt/config.yml
? File exists. Overwrite? Yes

This will write a default config.yml file to the user's home config directory. Mostly to enable getting up and running quickly with local Flipt

---

Here is the config it generates:

# yaml-language-server: $schema=https://raw.githubusercontent.com/flipt-io/flipt/main/config/flipt.schema.json

version: "1.0"
log:
  level: INFO
  encoding: console
  grpc_level: ERROR
ui:
  default_theme: system
cors:
  enabled: false
  allowed_origins:
    - '*'
server:
  host: 0.0.0.0
  http_port: 8080
  https_port: 443
  grpc_port: 9000
storage:
  type: database
db:
  url: file:/Users/markphelps/Library/Application Support/flipt/flipt.db
  max_idle_conn: 2
  prepared_statements_enabled: true
meta:
  check_for_updates: true
  telemetry_enabled: true

Also

• Finally removes deprecated config options older than (deprecated since) 6+ months
• Changes all command errors (atleast initial errors) to go to stderr instead of using the zap logger / fatal, which logs them to stdout at ERROR level, reasoning is below

On Errors

Going forward, I think we should adopt the position that there are two types of errors:

• Errors that stop a command from starting to run, like invalid arguments (ie: flipt foo). These errors should be logged to STDERR without logging/formatting
• Errors that occur after a command has started, ie runtime errors. I think these errors should be logged using our zap logger which is configured by the user, and logged at ERROR log level.

[codecov]

Codecov Report

Merging #2147 (940da83) into main (2f3f66d) will decrease coverage by 0.07%.
Report is 1 commits behind head on main.
The diff coverage is 44.00%.

@@            Coverage Diff             @@
##             main    #2147      +/-   ##
==========================================
- Coverage   70.25%   70.18%   -0.07%     
==========================================
  Files          76       76              
  Lines        7167     7151      -16     
==========================================
- Hits         5035     5019      -16     
+ Misses       1837     1834       -3     
- Partials      295      298       +3     

Files Changed	Coverage Δ
internal/cmd/http.go	3.10% <0.00%> (+0.07%)	⬆️
internal/config/config.go	87.16% <0.00%> (-0.04%)	⬇️
internal/config/cors.go	100.00% <ø> (ø)
internal/config/database.go	91.66% <ø> (ø)
internal/config/deprecations.go	57.14% <ø> (-42.86%)	⬇️
internal/config/experimental.go	100.00% <ø> (ø)
internal/config/meta.go	100.00% <ø> (ø)
internal/config/server.go	93.75% <0.00%> (-6.25%)	⬇️
internal/config/storage.go	81.69% <ø> (ø)
internal/config/ui.go	100.00% <ø> (ø)
... and 5 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[yquansah]

I wonder if we do need all the Redis cache stuff written out to the configuration file if cache is turned off by default

[markphelps]

I wonder if we do need all the Redis cache stuff written out to the configuration file if cache is turned off by default

yeah that's a good point, would require us to implement custom MarshalJSON and MarshalYAML methods for the CacheConfig struct, but that's prob not a bad idea. The same could be said for tracing as well.

We should prob come up with a rubric of where to draw the line as in what gets written to the default config and what doesn't.

Like should authentication and audit also be written to the default config? even though they are not enabled by default either? But to enable them you have to enable one of their sub properties (methods/sinks)

[markphelps]

I wonder if we do need all the Redis cache stuff written out to the configuration file if cache is turned off by default

yeah that's a good point, would require us to implement custom MarshalJSON and MarshalYAML methods for the CacheConfig struct, but that's prob not a bad idea. The same could be said for tracing as well.

We should prob come up with a rubric of where to draw the line as in what gets written to the default config and what doesn't.

Like should authentication and audit also be written to the default config? even though they are not enabled by default either? But to enable them you have to enable one of their sub properties (methods/sinks)

@yquansah checkout the updated output in the PR description to see what I got it down to

[yquansah]

@markphelps This looks good to me!