Fix CLI overrides LogLevel value from config file

[RubenCerna2079]

Why make this change?

• Closes issue [Bug]: CLI overrides LogLevel value from config file when it shouldn't #3258
  Whenever we use the dab start command the CLI overrides the minimum LogLevel from the configuration file. This is acceptable only if we use the --LogLevel flag. If we do not use that flag, the LogLevel for each namespace should be decided by the configuration file.

What is this change?

This change moves the args.Add methods inside the ConfigGenerator.cs so that they are only applied when we use the --LogLevel flag. Having these arguments causes DAB to not allow any changes to the LogLevel in the loggers, since those arguments were always being added, DAB always assumed the CLI was overriding the LogLevel when it was not expected as it would use the --LogLevel flag to determine if it was an IsLogLevelOverridenByCli scenario.

How was this tested?

• Integration Tests
• Unit Tests
• Manual Tests
  Tested with different configurations of the namespaces in the log-level property inside the config file.
  Note: ALL these manual tests were tested by running the CLI as well as running DAB through Visual Studio.
  Config file includes:

"log-level": {
    "Azure.DataApiBuilder.Core.Services.ISqlMetadataProvider": "Information",
    "Azure.DataApiBuilder.Core": "Debug",
    "Azure.DataApiBuilder.Config.FileSystemRuntimeConfigLoader": "Error",
    "default": "Warning"
}

Expected results:

• All the logs from Azure.DataApiBuilder.Core.Services.ISqlMetadataProvider will provide logs from log level information and above.
• All logs from Azure.DataApiBuilder.Core and its sub-namespaces that are not from ISqlMetadataProvider will provide logs from log level debug and above.
• All logs from Azure.DataApiBuilder.Config.FileSystemRuntimeConfigLoader will provide logs from log level error and above.
• Everything else will provide logs from log level warning and above, including CLI.

Config file includes:

"log-level": {
    "Azure.DataApiBuilder.Core": "Information",
    "Azure.DataApiBuilder.Config": "Debug",
}

Expected results:

• All logs from Azure.DataApiBuilder.Core and its sub-namespaces will provide logs from log level information and above.
• All logs from Azure.DataApiBuilder.Config and its sub-namespaces will provide logs from log level debug and above.
• Everything else will provide logs from log level debug and above with host.mode = development, including CLI.

Config file includes:

"log-level": {
    "Default: none
}

Expected results:

• No logs will be printed, including CLI.

Sample Request(s)

dab start --LogLevel information

dab start (With config file default value debug)

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Fixes dab start so the CLI only overrides the minimum LogLevel when --LogLevel is explicitly provided, allowing config-file log levels to take effect otherwise.

Changes:

• Move --LogLevel argument injection to only occur when StartOptions.LogLevel is set.
• Improve logging to differentiate whether the log level came from config’s default namespace vs host-mode fallback.
• Add an end-to-end test validating Startup.IsLogLevelOverriddenByCli behavior with/without the --LogLevel flag.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/Cli/ConfigGenerator.cs	Stops always appending --LogLevel args; adds logic to detect config-provided default log level for logging.
src/Cli.Tests/EndToEndTests.cs	Adds an E2E test for CLI log level override behavior by asserting Startup.IsLogLevelOverriddenByCli.

[Aniruddh25]

Needs answers to some questions, and more testing

[anushakolan]

Apart from the unit tests, did you manually test it via CLI, if the behavior is as expected. It would be good to have the manual testing section as well in the PR description.

[Aniruddh25]

Approving assuming the else part will be removed completely.

[anushakolan]

Apart from the unit tests, did you manually test it via CLI, if the behavior is as expected. It would be good to have the manual testing section as well in the PR description.

I will re-review after this is addressed. Some cases specific to namespace logging testing is also good to add.