Comments (8)
What if we just used a dedicated color for the messages from the controller and removed that color from the pool used for the other processes?
from workflow-cli.
Right now, we add the integer value of all the characters in the process title and divide by the number of colors, taking the remainder as the selected color.
It's a very simple, but very stupid solution.
In this situation, the integer value of the sum of the characters for both the controller process type and the other process type have the same remainder, giving them the same color. In order to prevent this, we would need to stop using this algorithm and instead would need to save all the process titles in the output and their assigned color to prevent repeats to the greatest possible degree.
from workflow-cli.
because then we're adding client-level implementation details into the API response. If someone were to extend the API in another language or in an environment where pretty colors are not important, that data would be useless.
fwiw Heroku colors their logs based on the process type and process number as well (e.g. web.1
would be different than web.3
in most cases). Color collisions mostly occur due to the lack of colors a TTY provides (8 + default uncolored text). If we had a full color spectrum then this wouldn't occur very often, if at all.
from workflow-cli.
because then we're adding client-level implementation details into the API response. If someone were to extend the API in another language or in an environment where pretty colors are not important, that data would be useless.
afaik, this doesn't involve touching the API at all. Colorizing is done entirely by the CLI. I'm suggesting that we could us a regex, perhaps, to distinguish log messages originating from the controller from those originating from application processes. By doing that, we could reserve a dedicated color for the controller.
imo, the logs originating from the controller are special because they are indicative of administrative functions that have been performed upon the app. I think it's important that those not get "lost" in a sea of logs viewed via the client.
from workflow-cli.
Colorizing is done entirely by the CLI.
Or have I got that wrong? I'm questioning it now.
from workflow-cli.
No, you've got it right. prettyprint is the package we use to colorize the logs. All done on the client side. :)
By doing that, we could reserve a dedicated color for the controller.
That would be a happy medium. Just reserve one of the 8 colors for the controller, then use the rest of the color wheel for the application logs. That way the controller is guaranteed to be different from the rest.
I vote for Magenta
afaik, this doesn't involve touching the API at all.
Sorry, I was responding to
What if we just used a dedicated color for the messages from the controller and removed that color from the pool used for the other processes?
And thought you meant literally attaching a color code to the log and shipping that in the response. I mis-interpreted your proposal. My bad! :)
from workflow-cli.
No worries. And I like magenta.
from workflow-cli.
I opened PR #132 to fix this.
from workflow-cli.
Related Issues (20)
- Buildpack for Ruby fails to parse a particular syntax HOT 3
- use go-rootcerts to support custom PKI on darwin HOT 3
- deis config should handle base64 encoded SSH_KEY
- master branch not building; codecov issue? HOT 1
- Custom HTTP-Headers for Readiness-Checks ignored HOT 2
- Support Heroku app.json file HOT 2
- config:push with .env doesn't handle export or double quotes HOT 4
- feat(client): Teach option flag for tracing requests HOT 2
- config:push with .env does not support multline HOT 11
- Publisher fails to parse HEALTHCHECK_INITIAL_DELAY if the value contains `\r` HOT 2
- Add config:diff
- deis create in a non-git directory should run with --no-remote HOT 5
- [Feature request] Automatic deis profile selection based on git remote HOT 1
- Move workflow-cli binaries to Azure Blob Storage HOT 1
- Get rid of stdin for deis config:push HOT 2
- Consider disabling automatic Procfile lookup for deis pull HOT 2
- apps:destroy should have a more explicit help message HOT 5
- deis releases returns requested URL not found HOT 5
- deis registry:unset unauthorized HOT 4
- Url : permission denied HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from workflow-cli.