feat: Honor FORCE_COLOR for logging#10139
Conversation
✅ Deploy Preview for docs-meltano ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Reviewer's guide (collapsed on small PRs)Reviewer's GuideUpdate default logging configuration to honor the FORCE_COLOR environment variable for colored logging while preserving NO_COLOR precedence and existing TTY-based behavior, and align tests with the new behavior by removing an xfail marker. Flow diagram for colored logging decision with FORCE_COLORflowchart TD
A["stderr_is_tty = sys.stderr.isatty()"] --> C
B["force_color = get_boolean_env_var(FORCE_COLOR)"] --> C
D["no_color = get_no_color_flag()"] --> E
C["tty_or_force = stderr_is_tty OR force_color"] --> E
E["colors = tty_or_force AND NOT no_color"] --> F["Emit colored log output"]
E --> G["Emit non-colored log output"]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- Consider avoiding the hard-coded "FORCE_COLOR" string in
default_configby centralizing it as a constant or reusing an existing helper, so changes to the env var name only need to happen in one place.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider avoiding the hard-coded "FORCE_COLOR" string in `default_config` by centralizing it as a constant or reusing an existing helper, so changes to the env var name only need to happen in one place.
## Individual Comments
### Comment 1
<location path="tests/meltano/core/logging/test_logging_utils.py" line_range="74" />
<code_context>
False,
"\x1b[2m2021-01-01T00:00:00Z\x1b[0m [\x1b[32minfo \x1b[0m] \x1b[36mmeltano \x1b[0m \x1b[1mtest \x1b[0m", # noqa: E501
id="colored-non-tty-force-color",
- marks=(
- pytest.mark.xfail(
</code_context>
<issue_to_address>
**suggestion (testing):** Add an explicit test case for `FORCE_COLOR` + `NO_COLOR` precedence
With `colored-non-tty-force-color` now enabled, please also add a test that sets both `FORCE_COLOR` and `NO_COLOR` and asserts that colors are disabled. This will encode the intended precedence and guard against regressions where `FORCE_COLOR` incorrectly wins over `NO_COLOR`.
Suggested implementation:
```python
False,
"\x1b[2m2021-01-01T00:00:00Z\x1b[0m [\x1b[32minfo \x1b[0m] \x1b[36mmeltano \x1b[0m \x1b[1mtest \x1b[0m", # noqa: E501
id="colored-non-tty-force-color",
),
pytest.param(
LogFormat.uncolored,
False,
"2021-01-01T00:00:00Z [info ] meltano test ",
id="uncolored-non-tty-force-and-no-color",
),
pytest.param(
LogFormat.uncolored,
```
To fully implement the precedence test, you should:
1. Ensure this new `pytest.param` is included in the same parametrized test that configures environment variables. Mirror the pattern used by other cases (e.g., existing `NO_COLOR` or `FORCE_COLOR` cases) to set both `FORCE_COLOR` and `NO_COLOR` for this `id="uncolored-non-tty-force-and-no-color"` case.
2. If environment setup is driven by parametrized marks (like `marks=pytest.mark.parametrize` or custom marks that inject `env`), add the appropriate mark so that `FORCE_COLOR` and `NO_COLOR` are both set in the environment for this case, and verify that the logging output matches the uncolored string above.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #10139 +/- ##
=======================================
Coverage 96.79% 96.79%
=======================================
Files 286 286
Lines 25960 25962 +2
Branches 1493 1493
=======================================
+ Hits 25127 25129 +2
Misses 671 671
Partials 162 162 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
82e9a6a to
bf6a13a
Compare
bf6a13a to
e57026d
Compare
|
I pushed an amended commit to isolate the existing CLI color tests from any ambient FORCE_COLOR value in CI. Since this PR intentionally makes FORCE_COLOR affect default logging colors, the older NO_COLOR-focused CLI test cases now explicitly clear FORCE_COLOR before asserting non-TTY behavior. |
|
The two remaining failed checks appear to be unrelated tracking/Snowplow tests rather than the logging color path changed by this PR:
The logging-related tests touched by this PR are passing locally, including the FORCE_COLOR and NO_COLOR precedence cases. Could @edgarrmondragon please rerun the failed jobs it seems I am not able to rerun those two? |
FORCE_COLOR for logging
edgarrmondragon
left a comment
There was a problem hiding this comment.
Thanks @gbadedata!
We should mention FORCE_COLOR support in https://deploy-preview-10139--docs-meltano.netlify.app/reference/command-line-interface, and clarify the precedence between it and NO_COLOR.
Also, an admonition block explaining that this was added in Meltano v4.3.0:
:::tip
`FORCE_COLOR` support was added in v4.3.0
:::
that way readers are not left wondering why it doesn't work if they read this before we publish it.
Summary
Follow-up to #10118.
This updates Meltano’s generated default logging configuration to honor
FORCE_COLORwhen deciding whether to emit colored log output.The change keeps the existing precedence:
NO_COLORstill disables colors.FORCE_COLORenables colored logging when stderr is not a TTY.Details
The colored logging path now enables colors when either stderr is attached to a TTY or
FORCE_COLORis truthy:This preserves
NO_COLORprecedence because the final condition still requiresnot get_no_color_flag().The existing
colored-non-tty-force-colortest case already described the intended behavior and was markedxfailbecauseFORCE_COLORwas not honored. This PR implements that behavior and removes thexfail.Tests
Results:
test_default_logging_config_format: 7 passedgit diff --checkpassedSummary by Sourcery
Honor the FORCE_COLOR environment variable in default logging configuration so colored logs can be enabled even when stderr is not a TTY, while preserving NO_COLOR precedence.
Bug Fixes:
Tests: