Design specification for improved Console output #1063

eriwen · 2016-12-23T17:25:47Z

This is a first pass at a Console implementation that displays background work and parallel work to the user.

bmuschko · 2016-12-23T17:30:00Z

design-docs/improved-console.md

+* User extensibility
+
+### User Goals for Console
+In priority order, the user wants to answer the following questions:


I'd think different users have different priorities. Personally, I'd be mostly interested in "what Gradle is going now" as top priority.

Mostly that those 2 priorities are actually high on users' lists and we're addressing them is more important than the ordering. How would you change the look of the Console if these goals were reordered?

I don't think it's important to indicate a priority in the introduction. I would have just said that these are the goals with out a specific order. The priority of work items is already laid out by the stories below.

bmuschko · 2016-12-23T17:33:29Z

design-docs/improved-console.md

+* Is my build successful?
+* What command did I execute?
+
+## Story: Display parallel work in-progress independently by operation


From what I understand this story lays the ground work for customizing individual portions of the new console display layout. I'd try to reflect that in the title. Follow up stories describe the exact look & feel + behavior. Is this story meant to be a general description without the actual implementation? If we do implement something in this story how will the individual portions of RichConsole look like?

bmuschko · 2016-12-23T17:34:42Z

design-docs/improved-console.md

+Show incomplete ProgressOperations on separate lines, up to a specified maximum number. 
+
+### Implementation
+A `RichConsole` has 


You use these class names? Could we spell out what they actually are, what their purpose is and where they live? Without trying to look it up I am assuming they are existing Gradle core classes?

They are yet-to-be created interfaces for the most part, intended to be an attempt at domain modeling.

Let's add the interfaces in this story including their proposed methods to get a better idea. That would outline their concrete responsibilities.

bmuschko · 2016-12-23T17:35:20Z

design-docs/improved-console.md

+
+The `ProgressLabel` is intended to give the user a glance-able indicator that tells
+them whether the build will be finished soon or not. 
+See ["Display build progress as a progress bar through colorized output"](TODO) below.


Missing link

bmuschko · 2016-12-23T17:36:15Z

design-docs/improved-console.md

+* What command did I execute?
+
+## Story: Display parallel work in-progress independently by operation
+Show incomplete ProgressOperations on separate lines, up to a specified maximum number. 


A simple mock up would help a lot with visualizing the end result.

See our internal projects board for a demo. I have other demos pending.

bmuschko · 2016-12-23T17:37:15Z

design-docs/improved-console.md

+* Renders well on default macOS Terminal, default Windows Console, Cygwin, and common Linux Terminals
+* Console display degrades gracefully given BuildOperations that are out-of-order (e.g. complete event received before start)
+
+### Open issues


Do we have appropriate fallback logic that kicks in if the console doesn't support the feature? What behavior + look & feel does it fall back to?

Yes, currently we have logic that disables the AnsiConsole if we detect that the attached console doesn't support color or is "dumb". You can get a feel for what this'd look like if you use TERM=dumb ./gradlew task

bmuschko · 2016-12-23T17:37:35Z

design-docs/improved-console.md

+* Is my build successful?
+* What command did I execute?
+
+## Story: Display parallel work in-progress independently by operation


How will the functionality be introduce to the user? Is it an opt-in feature? Can be turned off/on.

Good question. I'll answer this in the spec.

bmuschko · 2016-12-23T17:38:17Z

design-docs/improved-console.md

+[terminfo](https://en.wikipedia.org/wiki/Terminfo)-based Console handling instead of using ANSI.
+
+### Test Coverage
+* A terminal size with fewer than max parallel operations shows (rows - 2) operations in parallel


What's the expected behavior for that test case?

I should clarify the statement. The key part is "shows (rows - 2) operations in parallel"

bmuschko · 2016-12-23T17:39:10Z

design-docs/improved-console.md

+### Test Coverage
+* A terminal size with fewer than max parallel operations shows (rows - 2) operations in parallel
+* Operation status lines are trimmed at (cols - 1)
+* `System.in` and SystemConsole I/O happens on the mainArea, which is unaffected by other areas


Does this mean we'll support this use case (see corresponding JIRA + GitHub issues)? I think that should be a separate story.

My hope is that we can implement this in such a way as to avoid the existing bug thereby not requiring "separate" work as opposed to a naive implementation that still breaks + a story to fix it.

bmuschko · 2016-12-23T17:39:42Z

design-docs/improved-console.md

+* Operation status lines are trimmed at (cols - 1)
+* `System.in` and SystemConsole I/O happens on the mainArea, which is unaffected by other areas
+* Renders well on default macOS Terminal, default Windows Console, Cygwin, and common Linux Terminals
+* Console display degrades gracefully given BuildOperations that are out-of-order (e.g. complete event received before start)


What is meant by "degrade"?

Will change to "gracefully handles"

This should be baked into the BuildOperation contract. Consumers should never receive complete events before start events, and producers should have no way to generate a complete event before a start event.

bmuschko · 2016-12-23T17:40:36Z

design-docs/improved-console.md

+
+### Open issues
+* How is `--continuous` build displayed? During execution? While waiting? (as we allow processes to stay running)
+* When things fail, will the new CLI look like a regular failure or something else?


How can get to error messages/stack traces/warnings that occurred during the build but have been overwritten?

They shall not be overwritten because they'll be written with log level WARN or higher and thus appear in the "main" TextArea.

It's not clear to me what happens if you get a lot of these message. From my what I understand the text are will show "what's currently going on the build" + warning and error messages. What happens if it fills up? How do we visually separate these two types of output?

I find it helpful to imagine it like this: The output looks exactly the same as it does today (with the "status" at the bottom) except that:

That status line is many lines instead of 1

Lifecycle logs are no longer output

We could visually separate these things by adding an empty line above the "status" text area if necessary.

bmuschko · 2016-12-23T17:42:01Z

design-docs/improved-console.md

+* Console display degrades gracefully given BuildOperations that are out-of-order (e.g. complete event received before start)
+
+### Open issues
+* How is `--continuous` build displayed? During execution? While waiting? (as we allow processes to stay running)


Maybe add some sort of indicator (like an icon or text with colorized background) to the text area that indicates that we are running a continuous build?

bmuschko · 2016-12-23T17:43:59Z

design-docs/improved-console.md

+### User-visible Changes
+We can visually represent complete, in-progress, and un-started tasks of build using colorized output:
+
+`#####green#####>##yellow##>#####black#####> 40% Building`


How's the percentage calculated? Based on the number of tasks as we have it right now? Will there be any more intelligence built-in? Should say what's out of scope.

We currently already calculate and display this percentage in the Status Bar. IIUC, it's the % of tasks complete from the calculated task graph at configuration time. We won't change this behavior IMO until we have sophisticated/historical timing data.

OK, that should be explicitly spelled out in the spec.

bmuschko · 2016-12-23T17:44:36Z

design-docs/improved-console.md

+
+Intended to give the user a very fast way of telling whether the build will be finished soon or not.
+The work-in-progress (yellow) section shows how much of the build would be complete if all
+Operations displayed in the progressArea completed.


Colorized output needs explanation and documentation. Maybe that is already an anti-pattern as it should be self-explanatory?

Please follow up with me on Slack about this. I'm confused by this question.

I think what @bmuschko means is that once you start having different colors in the progress bar, these colors need to be explained to the user or they need to have an immediately apparent meaning. Looking at progress bars in other programs I've rarely if ever seen a multi-color bar. It's usually a single solid color filling out an empty/neutral space.

bmuschko · 2016-12-23T17:45:20Z

design-docs/improved-console.md

+support them
+* ASCII-based, unstyled alternatives:
+```
+[##                        ] 6% Building


+1 for this option

bmuschko · 2016-12-23T17:46:22Z

design-docs/improved-console.md

+Each`RegionType` is associated with a color. This allows us to show failures in arbitrary locations
+as needed with `--continue`
+
+### Test Coverage


What's the output behavior if run from CI or and IDE?

Neither CI or IDEs attach to a Console, so their behavior will not change at all except for additional information they'll see from increased BuildOperations.

So the output would look as it looks right now?

Yes, exactly.

Depends whether the CI or IDE are using LongRunningOperation.setColorOutput(true) when they run Gradle via the tooling API. We should test this in some form.

bmuschko · 2016-12-23T17:46:42Z

design-docs/improved-console.md

+On ANSI terminals, we can use empty spaces with different background colors for the "bars" and
+A red background shall be used for failed tasks. 
+
+### Implementation


Needs to explain changes to TAPI

I hope there aren't any changes to TAPI necessary, just handling of additional types of BuildOperations. That has yet to be speced

bmuschko · 2016-12-23T17:47:49Z

design-docs/improved-console.md

+* Logs should be streamed with plain output and not throttled when not attached to a Console
+* The TAPI is unaffected except for additional BuildOperations now published
+* Logs should be streamed with plain output when attached Terminal lacks of color or cursor support
+* Renders well on default macOS Terminal, default Windows Console, Cygwin, PowerShell and common Linux Terminals


This will require extensive test fixtures and testing infrastructure e.g. we can't even test MACOS behavior via CI.

Rendering itself will be difficult to test as we don't know what font is used for the console which significantly affects display. Asciinema inspires me for this purpose, though. Can we use that somehow?

bmuschko · 2016-12-23T17:49:10Z

design-docs/improved-console.md

+«==========================» 100% BUILD SUCCESS
+```
+
+## Story: Display intra-operation progress


We should pick individual use cases and break them into different stories. I think an easy one would be "resolving dependencies". What's the behavior if executed in parallel?

bmuschko · 2016-12-23T17:51:14Z

design-docs/improved-console.md

+When we know in advance the number of things to be processed, we display progress in [Complete / All] format. 
+Provide APIs to optionally add # complete and # of all items.  
+
+For example:


I am missing a story that I consider a quick win. Render the completion of different phases in Gradle's lifecycle. Done initializing, done configuring, done executing. And then within these phases render individual events.

That's proposed below, though I disagree. I don't think it'd be quick and IMO I'm not yet convinced the value would be high. I'm happy to be convinced, though. Perhaps you can modify one of my demos (linked to internal issue) to show me what you're thinking.

I think we would just have to register a Listener and then render that we reached a certain stage. I think it would give a good indication of "as a user i want to know when the actual of execution of tasks really starts", "if configuration takes longer than I expected it to take - maybe there's something wrong my code".

If you watch the demo closely, we already show "Initializing, Configuring, and Executing" on the progress bar. They're just fast and are replaced with Executing quickly. Is that sufficient?

bmuschko · 2016-12-23T17:52:27Z

design-docs/improved-console.md

+### Open issues
+* Could this concept allow customization of ProgressLine format, providing even greater flexibility?
+
+## Story: Gradle-provided slick themes


I'd move this story before the previous one. We should ship with an existing theme before we make it customizable for the end user.

I'll respond to this in the design doc and with a demo, but there will be an ASCII based existing theme. However, this is a blocker for release IMO.

bmuschko · 2016-12-23T17:53:59Z

design-docs/improved-console.md

+### Open issues
+* Color choices we would use if we could
+
+## Story: (Optional) Illustrate build phases independently


See my comment above. I don't think this should be optional and should be moved before customizing things by the end user.

I'm looking forward to a concrete suggestion about what this would look like.

adammurdoch · 2016-12-23T19:49:30Z

design-docs/improved-console.md

+* Operation status lines are trimmed at (cols - 1)
+* `System.in` and SystemConsole I/O happens on the mainArea, which is unaffected by other areas
+* Renders well on default macOS Terminal, default Windows Console, Cygwin, and common Linux Terminals
+* Console display degrades gracefully given BuildOperations that are out-of-order (e.g. complete event received before start)


This should be baked into the BuildOperation contract. Consumers should never receive complete events before start events, and producers should have no way to generate a complete event before a start event.

adammurdoch · 2016-12-23T19:54:24Z

design-docs/improved-console.md

+and errors.
+
+`--quiet`, `--info`, and `--debug` log level flags affect the output visible in the main TextArea,
+However, the default will change so that `LIFECYCLE` logs are no longer displayed.


Something that is not entirely clear is how this relates to what we show in the main area now. I read this as saying that the main area will show exactly the same content as it does now, minus LIFECYCLE log messages.

It would also be useful to make clearer what happens when the build process is not attached to a terminal, in general.

I would think about including some context when we log an important message, as often the warning/error messages don't include enough context for a human to know which build operation (such as a task) the message relates to. This is particularly important when running in parallel, and logging things like compile error messages.

Currently the lifecycle logging serves this purpose (not perfectly), so if we remove it, we should add something else to help the user make sense of the error and logging messages.

adammurdoch · 2016-12-23T20:07:15Z

design-docs/improved-console.md

+Each`RegionType` is associated with a color. This allows us to show failures in arbitrary locations
+as needed with `--continue`
+
+### Test Coverage


Depends whether the CI or IDE are using LongRunningOperation.setColorOutput(true) when they run Gradle via the tooling API. We should test this in some form.

eskatos

This spec adds a lot of system properties for UI customization purpose. I'm not sure we want to go down that route. Another extension mechanism could be used, e.g. by letting users provide custom renderers/themes as a jar/class/plugin/extension. I don't know how it could work in details though.

eskatos · 2017-01-05T12:49:40Z

design-docs/improved-console.md

+org.gradle.console.progressbar.inprogress.suffix=""
+org.gradle.console.progressbar.unstarted.suffix=""
+org.gradle.console.progressbar.completechar=" "
+org.gradle.console.progressbar.completechar="#"


org.gradle.console.progressbar.completechar is present twice with a different value

- Provide more detail about parallel WIP is displayed and implemented - Add stories improve logging to give more context Issue: #1063

eriwen · 2017-01-05T22:00:15Z

@eskatos I investigated some ways to customize the Console output through provided classes, and I believe it would add significant implementation complexity and usage complexity. I removed 3 properties in the latest revision. If you think that is still problematic, can you explain why further?

oehme

I can't wait to actually see this in action :)

One thing the spec doesn't tackle at the moment is how nested operations are displayed. A worker might be executing the compileMainCpp task, which in turn is broken down into header compilation and object file compilation, which in turn could be broken down into per-file operations. What would the status line for that worker show? If we only show the lower-most operation, we'd get incomprehensible flickering. If we only show the top-most one we loose information in case something does actually take a long time. Maybe we could use some nested structure using > characters? Executing compileMainCpp > Compiling Headers > Compiling Foo.h.

oehme · 2017-01-16T10:17:24Z

design-docs/improved-console.md

+## Primary Goals
+* Improve perceived performance by making user aware of background work
+* Modern feel
+* User extensibility


I'd like to challenge this goal. What is the impact of being able to change the color theme/progress bar characters? What big problem does this solve or what exciting new development does it enable?

This is the difference between plain output and rich output — Given the current spec, I believe that if we want to achieve the latter (and I think we do) it is very little additional effort to allow users to do so. Node and Python tools have achieved a sense of modernism by including pretty (colorized, non-ASCII) output in their tools, and I think we should do the same.

Here the reasons I think that could be beneficial:

It gives users a new vehicle for contribution for Gradle. I believe someone out there has some crazy awesome ideas for the console UI

It gives users an easy way for colorized output to match the rest of their Terminal.

I'm on board with rich output, but doubt the value of configurability, at least as a main goal. I think it adds significant overhead to implementation, testing and documentation. I'd prefer us focusing our energy on a great default that is in line with our brand before we tackle configurability.

You're absolutely right — it is not a main goal and we'll consider it an optional last milestone.

oehme · 2017-01-16T10:18:56Z

design-docs/improved-console.md

+* What is Gradle doing right now?
+* Is my build successful?
+* What command did I execute?
+


Are there any other interesting outcomes, except success/failure? E.g. build scan

How much work did Gradle actually do vs. how much did Gradle save me (e.g. up-to-date, from-cache)?

How well is the build using the system resources?

I believe the first point should be added. I hesitate to consider the latter two. I personally get the sense that users really do not care at all about how Gradle achieve it's result. If they do, that's what build scans are for!

I think it is valuable to have a quick overview how much work was really done. We've seen on several occasions that users aren't even aware that their build is wrongly out of date because the many log messages make that hard to see. Now we are removing those log messages, so there is even less context to notice a problem. Just having a single percentage (work avoidance rate or something) could help raise awareness. I realize build scans show all this and much more, but consider this: Many users aren't aware that their build has a problem and just assume that a 10s turnaround is normal, so the idea of creating a scan doesn't even occur to them. This leads to the wrong sentiment of "Gradle is slow", when really they would just need to fix their build.

+1 for what Stefan said. This is also related to something we want to show for task output caching: https://github.com/gradle/task-output-cache/issues/302

oehme · 2017-01-16T10:20:00Z

design-docs/improved-console.md

+## Story: Display parallel work in-progress independently by operation
+Show incomplete ProgressOperations on separate lines, up to a specified maximum number. 
+
+This is opt-in initially by specifying the `org.gradle.console.parallel=true` Gradle property.


What is the reason for making this opt-in or configurable at all?

In this case I'm considering milestone releases where the console itself isn't usable for a given project — allowing a user to turn it off. This is a good question, though, I'd really, really like to not need this.

Okay I think we should call this out. For the 4.0 release this should be on by default, maybe with an opt out. And at some point we'll want to remove the code for the old output structure.

oehme · 2017-01-16T10:20:34Z

design-docs/improved-console.md

+The user wants to answer the following questions:
+
+* When will my build finish?
+    * Soon (should I keep watching it) or later ("I'll check back")


How would Gradle know when it will finish?

Gradle doesn't yet know when it'll finish, but it does know if it's working on the last task. That is something we're not surfacing to the user and should.

oehme · 2017-01-16T10:21:20Z

design-docs/improved-console.md

+with an optional worker ID to provide information about "where" an operation is running
+so that a mapping of worker to index of operation status line can be maintained.
+
+A `OperationStatusBarFormatter` can be used to customize the intra-line display of each 


What is the use case for making this configurable? Why not use the build operation's display name in all cases for consistency?

We currently have a DefaultStatusBarFormatter that adds the >s — this is very similar to that and doesn't have any user facing implications. In later stories, this might become configurable, but it's optional.

Okay I stumbled over the "can be used to customize". That sounds like a user api

oehme · 2017-01-16T10:50:41Z

design-docs/improved-console.md

+`org.gradle.console.theme=powerline` and substitute `PowerlineProgressBarRegion` 
+instead of the `DefaultProgressBarRegion`.
+
+## Story: (Optional) Customizable StatusBarFormat


I know I'm repeating myself now :) I don't think this is important and would rather have a consistent experience.

oehme · 2017-01-16T10:51:27Z

design-docs/improved-console.md

+### Open issues
+* How is intra-operation progress ([55 / 1234] or spinner) affected?
+
+## Story: (Optional) Indicate Gradle's continued progress in absence of intra-operation updates


I think this one should not be optional, as it very much affects perceived performance. I'd prioritize this over any kind of customizability.

A couple notes about this. I think you're almost certainly right that we need this. The thing that sucks is that everything that looks polished isn't compatible with nearly all terminal environments (console size, color, font, font-size, etc). I'll think harder about how this might look, but so far I've only come up with ugly solutions.

oehme · 2017-01-16T10:54:42Z

design-docs/improved-console.md

+Support detection and use of UCS-2 (default supported by Windows) or UTF-8 characters could further polish this if we choose.
+
+This would allow us to use characters like ᐅ or ► supported by a majority of monospace fonts.
+More granular width for progress bars: ' ', '▏', '▎', '▎', '▍', '▍', '▌', '▌', '▋', '▋', '▊', '▊', '▉', '▉', '█'


Since we don't know what portion of a build a task represents, I don't think we'll need different slice sizes. I'd just use a pretty small increment by default and draw as many of them as we need to visualize the completed percentage.

The vast majority of terminal fonts are monospace and so take up the same horizontal space regardless of the character, therefore we cannot draw many small increments — we must do N "wide" bars and then a "thinner" one.

On that note, we don't have control over the fonts used. Some may not have implementations for these characters and may display as placeholders (like some kind of boxed [x]).

This is one major reason I advocate for themes. Everyone's terminal environment is different. We cannot hope to develop a single "pretty" theme that works for everyone. I believe we must give users more options (even better, create their own)

I would assume (and that may be wrong) we can develop one that looks great for the 80% case. I'd worry about theming later/if we actually get requests.

Let's see what we can come up with. I think it's going to be really tough to get one that looks great for 80% of users. I want something that is viral because it's so awesome — that's likely not achievable.

oehme · 2017-01-16T10:56:24Z

design-docs/improved-console.md

+supports advanced features. 
+
+## Story: (Optional) "Fade out" operation result
+Tasks completed continue to be displayed for 1 more "tick" of the clock with their resolution status, 


If this is slow enough so I can actually read it, it'll hide what is actually being worked on right now.

Hmmm... we can probably remove this story. It would be cool but probably not practical.

oehme · 2017-01-16T11:09:58Z

design-docs/improved-console.md

+* Color choices we would use
+
+## Story: (Optional) Illustrate build phases independently
+Similar to "Display build progress as a progress bar through colorized output" above, but having clearly separated output for each build phase.


I would prioritize this over any customization. It improves several things:

Configuration time is usually a very small part of the build, so it would only be a single tick on the progress bar. Seeing a whole bar fill up quickly instead is much more engaging.

We don't even know how many tasks we'll execute before we calculate the task graph. By starting over we can size the increments correctly

Sorry for the confusion here. The current demo actually fills up the whole bar for each phase separately, it's just very fast. That is, we do already start over.

So this is about adding a phase label next to it?

Yes, that should be in the Progress Bar story. If not, I'll add it.

corneil · 2017-01-17T09:12:32Z

One thing that would be helpful is the ability to log detail to a file like with log4j or such and configuring log level for that file then a CI build can be fairly quiet and you can dig in the log file if needed. One of my customers has a project that builds more than 300 sub projects and Jenkins cannot handle the slave pushing that much detail if the build is logging debug level.

So being able to send the output to a file as well with control over which classes or tasks have which loglevels will help a lot.

oehme · 2017-01-17T10:27:15Z

@corneil I think adjusting Gradle's logging is out of scope for this story. It is about making Gradle more interactive when attached to a "smart" terminal. The use case you mentioned is definitely valid, but I think we should have a separate issue for that.

eriwen · 2017-01-17T16:42:11Z

@corneil We hear you and lots of others loud and clear on the logging front. We have some unpublished design specs to help address this. Expect to read some more about it later this year.

adammurdoch · 2017-01-18T02:29:32Z

design-docs/improved-console.md

+* Additions needed to `org.gradle.api.Logger` and `StyledTextOutput` for use in build scripts
+
+## Story: Allow user to include additional info in log messages
+Allow users to specify whether timestamp, log level, and/or category are logged with each message.


though I'm not sure this is strictly necessary.

100% a solution to the use case is necessary before we remove the task names. There's no way we should ask our users to detangle the error output of 8 different broken JavaCompile tasks where is all jumbled together and interleaved.

The proposed solution (Allow users to specify whether timestamp, log level, and/or category are logged with each message) doesn't really solve the problem.

Instead, I would do something like group the log output of a build operation (however that came to be) together and include either a header or a prefix. I would do this as a built-in capability and not something the task author or build author or build operator has to take action to enable.

adammurdoch · 2017-01-18T02:30:22Z

design-docs/improved-console.md

+# Milestone 1 - Show parallel WIP and summary
+
+## Story: Display parallel work in-progress independently by operation
+Show incomplete ProgressOperations on separate lines, up to a specified maximum number. 


BuildOperations, not ProgressOperations.

adammurdoch · 2017-01-18T02:31:36Z

design-docs/improved-console.md

+
+`TaskExecutionLogger` no longer sets logging headers. This prevents logging of task names
+in main area. To compensate for the user's loss of context, [WARN and ERROR logs can be 
+configured to give more context](#story-log-messages-can-be-configured-to-give-more-context),


Not configured, this should just be baked in and require no action by the task author or build author or build operator.

I would do this by generalizing what the task exection logger does and apply it to all BuildOperations that generate output.

adammurdoch · 2017-01-18T02:34:03Z

design-docs/improved-console.md

+```
+
+### Implementation
+`DefaultGradleLauncherFactory` registers a listener `BuildProgressBarListener` (similar to `BuildProgressFilter`)


I would instead have the task graph executor generate an event attached to the build operation that represents task execution, to indicate how many tasks will be executed. I wouldn't couple DefaultGradleLauncherFactory in to this.

In other words, move to towards the situation where the build operation event stream describes everything relevant to the visualisation of build execution. The thing that schedules and executes a sequence of build operations can, once it knows, inform consumers that care how many build operations it will be running.

Do we have similar constructs that could generate events for initialization and project configuration?

Yes, they're all build operations already. That's the point: don't add another ad hoc mechanism, instead add a general mechanism and reuse it for configuration, test execution, native compilation, dependency resolution, etc. It's the same amount of effort to add the general mechanism as it is to add the ad hoc mechanism.

adammurdoch · 2017-01-18T02:37:31Z

design-docs/improved-console.md

+### Open Issues
+* How is buildSrc rendered?
+* How are composite builds rendered?
+* How are GradleBuild tasks rendered?


For these, the answer is: same as everything else. Build operation events are generated for these builds.

adammurdoch · 2017-01-18T02:41:04Z

design-docs/improved-console.md

+```
+
+### Implementation
+`BuildProgressBarListener` implements a TestExecutionListener (TBD) and


Should instead replace TestListenerInternal with build operation events.

adammurdoch · 2017-01-18T02:52:13Z

+1 to very low priority for customisation. I would do it through an API that plugins can mess with, so I can easily package my customisations (which will sometimes include logic) and share them with others.

Issue: gradle/gradle-private#510

- Add domain modeling information where possible - Split WIP on progress bar to separate story - Flesh out implementation details for some stories Issue: gradle-private#510

Issue: gradle-private#510

- Provide more detail about parallel WIP is displayed and implemented - Add stories improve logging to give more context Issue: #1063

- Introduce 4 deliverable milestones - Removed stories that will almost certainly not be handled - Add stories for some BuildOperation improvements Issue: gradle-private#510

eriwen added the from:member label Dec 23, 2016

eriwen requested review from bmuschko and oehme December 23, 2016 17:25

bmuschko reviewed Dec 23, 2016

View reviewed changes

design-docs/improved-console.md

support them

* ASCII-based, unstyled alternatives:

```

[## ] 6% Building

Copy link

Contributor

bmuschko Dec 23, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for this option

bmuschko reviewed Dec 23, 2016

View reviewed changes

adammurdoch reviewed Dec 27, 2016

View reviewed changes

eskatos reviewed Jan 5, 2017

View reviewed changes

eriwen added a commit that referenced this pull request Jan 5, 2017

Rework some stories of console spec and add logging improvements

40cbc83

- Provide more detail about parallel WIP is displayed and implemented - Add stories improve logging to give more context Issue: #1063

eriwen assigned oehme Jan 6, 2017

oehme suggested changes Jan 16, 2017

View reviewed changes

adammurdoch requested changes Jan 18, 2017

View reviewed changes

eriwen added 7 commits January 20, 2017 12:51

Draft design specification for improved Console output

f7dd6aa

Issue: gradle/gradle-private#510

Add more details to improved console spec

50102d3

- Add domain modeling information where possible - Split WIP on progress bar to separate story - Flesh out implementation details for some stories Issue: gradle-private#510

Add design concerns to improved console spec

3e8daf3

Issue: gradle-private#510

Rework some stories of console spec and add logging improvements

d2c640d

- Provide more detail about parallel WIP is displayed and implemented - Add stories improve logging to give more context Issue: #1063

Address more design feedback and introduce milestones

16d5df7

- Introduce 4 deliverable milestones - Removed stories that will almost certainly not be handled - Add stories for some BuildOperation improvements Issue: gradle-private#510

Address more design feedback

76b4cbe

Address feedback on Console design

3458567

eriwen force-pushed the ew-improved-console-spec branch from a215c47 to 3458567 Compare January 20, 2017 20:14

eriwen added 2 commits January 20, 2017 14:33

Additional Console spec cleanup

5dda0b9

Console spec cleanup

3049537

eriwen merged commit e30f912 into master Jan 25, 2017

eriwen deleted the ew-improved-console-spec branch January 25, 2017 17:27

Design specification for improved Console output #1063

Design specification for improved Console output #1063

Conversation

eriwen commented Dec 23, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmuschko Dec 23, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmuschko Dec 23, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eskatos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eriwen commented Jan 5, 2017

oehme left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eriwen commented Dec 23, 2016 •

edited

Loading

bmuschko Dec 23, 2016 •

edited

Loading

bmuschko Dec 23, 2016 •

edited

Loading