Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Disable color logs when not a terminal #462

Open
yermulnik opened this issue Jun 13, 2024 · 3 comments
Open

[Feature request] Disable color logs when not a terminal #462

yermulnik opened this issue Jun 13, 2024 · 3 comments
Labels
enhancement Refactor existing code for better performance and quality new feature New feature or request output Typos, log messages and better output

Comments

@yermulnik
Copy link
Collaborator

yermulnik commented Jun 13, 2024

Is your feature request related to a problem? Please describe.
At the moment tfswitch outputs logs with colors no matter whether it is run interactively or from within automation. Along with this when running within CI/CD or when tfswitch output is piped to another command or is written to a log-file it may be desired to log to console w/o colors to avoid vomiting console with escape sequences.

Describe the solution you'd like

  • Default behavior: color output (same as it is at the moment)
  • Non-terminal (non-interactive): force no color automatically (and add --force-color cmdline arg so users can enable color output explicitly) OR add --no-color cmdline arg to let user decide explicitly per use-case (additionally consider NO_COLOR env var: https://no-color.org/)
    • Add respective TOML config option for whichever option is considered

💡 Forcing color in non-interactive mode might be preferred e.g. when running within CI/CD pipeline that supports rendering ANSI escape sequences (e.g. https://plugins.jenkins.io/ansicolor/).

Additional context
Refs:

@yermulnik yermulnik added new feature New feature or request output Typos, log messages and better output enhancement Refactor existing code for better performance and quality labels Jun 13, 2024
@MatthewJohn
Copy link
Collaborator

I guess this could be done at the same time as #451

@yermulnik
Copy link
Collaborator Author

I guess this could be done at the same time as #451

"at the same time" as in you could be working on both? 🙏🏻
I think we should try and split different features into different PRs.

@yermulnik
Copy link
Collaborator Author

Another use case: #474

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Refactor existing code for better performance and quality new feature New feature or request output Typos, log messages and better output
Projects
None yet
Development

No branches or pull requests

2 participants