-
Notifications
You must be signed in to change notification settings - Fork 8
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
Get rid of fluttered build job output and color errors #374
base: master
Are you sure you want to change the base?
Conversation
063866d
to
0161414
Compare
2339aef
to
a337e8a
Compare
a337e8a
to
8ef121d
Compare
tested updated version, looks much better now - thanks! |
e9bdda4
to
65bb663
Compare
Signed-off-by: Nico Steinle <nico.steinle@eviden.com>
This will minimize text flutter when building many packages ``` - before: [00:00:06] (100%): █████ | [endpoint-name/XXXXXXX XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX package-name package_version]: msg - after: [00:00:06] (100%): █████ | endpoint-name XXXXXXX XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX ██ package_name package_version msg ^^^^^^^^^^^^^--- gets cut when longer than 6characters ^^--- colored build status block ``` Signed-off-by: Nico Steinle <nico.steinle@eviden.com>
The change to this specific formatting was requested by many users since it makes the output look cleaner Signed-off-by: Nico Steinle <nico.steinle@eviden.com>
65bb663
to
bdb7f3e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't test it yet but based on the diff the new format looks acceptable. Some of the format/color changes make a lot of sense but there are also some that I'm not really sure about. The implementation and commit messages require a bit of work though.
@@ -12,7 +12,7 @@ compatibility = 1 | |||
# fit a 80 or 100 character wide terminal! | |||
# | |||
# This is also the default if the setting is not present. | |||
progress_format = "[{elapsed_precise}] ({percent:>3}%): {bar:40.cyan/blue} | {msg}" | |||
progress_format = "{elapsed_precise} {percent:>3}% {bar:5.cyan/blue} | {msg}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we change the example here that we also should change the default (s. comment above):
Lines 14 to 17 in 0a15748
/// The default progress bar format | |
pub fn default_progress_format() -> String { | |
String::from("[{elapsed_precise}] ({percent:>3}%): {bar:40.cyan/blue} | {msg}") | |
} |
@@ -38,6 +38,8 @@ use crate::job::JobResource; | |||
use crate::job::RunnableJob; | |||
use crate::log::LogItem; | |||
|
|||
pub const MAX_ENDPOINT_NAME_LENGTH: usize = 6; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should try hard to avoid such magic constants. This one is especially a no-go as it depends on user defined endpoint names so we cannot simply cap the length to 6 here. One option would be to dynamically determine the max length by iterating over all configured endpoint names.
@@ -371,7 +373,6 @@ struct LogReceiver<'a> { | |||
impl<'a> LogReceiver<'a> { | |||
async fn join(mut self) -> Result<String> { | |||
let mut success = None; | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Such unrelated changes should be avoided but it's kinda ok here.
@@ -420,12 +421,12 @@ impl<'a> LogReceiver<'a> { | |||
self.bar.set_position(u as u64); | |||
} | |||
LogItem::CurrentPhase(ref phasename) => { | |||
trace!("Setting bar phase to {}", phasename); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Why drop the trace output?
self.container_id_chrs, | ||
self.job.uuid(), | ||
"██".yellow(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, what's the motivation behind this (cc @christophprokop)? Seems to be a "Full Block" Unicode character (https://www.compart.com/en/unicode/U+2588). I'm not sure if it's really a good idea to put Unicode characters in the source code and output. Theoretically we'd have to check if the language and terminal supports this but I guess we can make Unicode support a requirement nowadays.
"", // endpoint_name | ||
"", // container_id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this is still WIP / didn't get finished?
"", // endpoint_name | ||
"", // container_id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
"", // endpoint_name | ||
"", // container_id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again :P
Edit: Quite a few more occurrences throughout the rest of the file :o :D
self.jobdef.job.package().name(), | ||
self.jobdef.job.package().version(), | ||
msg = errmsg | ||
msg = errmsg.yellow() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: Should the error message really be yellow instead of red? Is this because of the inherited/propagated errors?
self.jobdef.job.uuid(), | ||
"██".white(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: White might not be ideal for terminals with white backgrounds but I'm not sure if there's a better alternative.
@christophprokop can you perhaps also provide motivation/background for or rather reasoning behind the output format changes? The things that seem obvious:
What I'm not sure about:
|
No description provided.