Feature Overview:

Our builder logs are currently very verbose at the INFO level.
This is a deliberate, practical choice for real-time debugging of long-running CI jobs.

However, this approach:

1. Is an anti-pattern: It misuses the INFO level for what are semantically DEBUG messages, coupling the log's content with a specific consumption need (the CI console).
2. Causes big log files at INFO level: It's impossible to get a "true" INFO-only log stream. This blocks new, high-value use cases like automated analysis by AI models, which cannot read files that big, even when using the INFO log-level.

This initiative will refactor our logging to be semantically correct and flexible, satisfying both build debugging workflows, and analysis requirements.

An example log can be seen here.

Goals:

• Set appropriate, semantically-correct log-levels to logs.

• Preserve the current state of monitoring and debugging build failures, and long-running CI jobs in real-time.

• Reduce info-level log files sizes.

Suggestions (Discussion required):

• Add a TRACE Log Level: This involves a full re-classification. We'd add a TRACE level below DEBUG, move all current DEBUG logs to TRACE, and move the verbose INFO logs to DEBUG. The CI console would then be set to show the DEBUG level, leaving the INFO level clean for analysis. This is semantically correct, but requires a refactoring effort.

• Re-purpose the DEBUG Level: This assumes the current DEBUG logs are "too noisy" because they are rarely, if ever, used. We would first investigate if these logs are actually needed. If not (since we don't appear to be using them when debugging issues in the build) we can remove them. Or at least a big chunk of them, if they're not really helpful. Then, we simply move the verbose INFO logs to the now-clean DEBUG level. The CI console would be set to DEBUG, solving both problems with the lowest refactoring effort.