Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 383023

Summary: [activity] extend the TreeViewer for additional build data
Product: z_Archived Reporter: Timur Achmetow <achmetow84>
Component: MylynAssignee: Timur Achmetow <achmetow84>
Status: CLOSED MOVED QA Contact:
Severity: enhancement    
Priority: P3 CC: sam.davis, steffen.pingel
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on:    
Bug Blocks: 376233    
Attachments:
Description Flags
test results from the build editor
none
builds view
none
first implementation of the associated build data
none
changed hierarchy none

Description Timur Achmetow CLA 2012-06-19 16:16:22 EDT
Here can we discuss which "build data" we want to show in the TableViewer. 
For example: if the build was successfull or not; and how much tests failures exist etc.
Comment 1 Steffen Pingel CLA 2012-06-20 18:52:03 EDT
That's a great idea to show the test summary. Maybe we could use similar information to what is shown in the Summary column in the Builds view?
Comment 2 Timur Achmetow CLA 2012-06-21 18:04:26 EDT
Created attachment 217723 [details]
test results from the build editor

You mean like the data in the screenshot?
Comment 3 Steffen Pingel CLA 2012-06-21 18:38:32 EDT
Created attachment 217725 [details]
builds view
Comment 4 Steffen Pingel CLA 2012-06-21 18:39:16 EDT
I was thinking of the overall build status and the summary displayed in the builds view but it's very close to what you had.
Comment 5 Timur Achmetow CLA 2012-06-23 06:24:20 EDT
Okay I understand; you want to show the whole content from the builds view?
Comment 6 Steffen Pingel CLA 2012-06-25 17:03:04 EDT
If we can show that information it would make sense to me but status + summary would be sufficient initially.

Builds aren't tasks but they stored in a separate data model. There isn't currently a way to search for builds and only the last build of a plan is stored in the data model. I think we would need some sort of cache where builds are persisted.

How about this as an initial pass: Query the data model that is available through BuildsUi.getModel() and show all builds that we can associate with the task?
Comment 7 Timur Achmetow CLA 2012-06-26 17:11:24 EDT
(In reply to comment #6)
> How about this as an initial pass: Query the data model that is available
> through BuildsUi.getModel() and show all builds that we can associate with the
> task?

Okay to show the whole content from the Builds View is not a problem. 
But at the moment I can't associate a task with the build. Or is this possible?

From the method BuildsUi.getModel() I get a List with IBuild objects,
but this objects haven't any associations to tasks ... ??
Comment 8 Timur Achmetow CLA 2012-06-29 19:00:41 EDT
contributions are here: https://git.eclipse.org/r/#/c/6545/
more details here: http://wiki.eclipse.org/Mylyn/Activity_Tracing_For_Mylyn
Comment 9 Timur Achmetow CLA 2012-06-29 19:05:45 EDT
Created attachment 218116 [details]
first implementation of the associated build data

The TreeViewer contains the associated builds to a task. 
The Viewer list all projects which are affected and shows following informations: 
 - project name
 - test summary
 - last build run
Comment 10 Steffen Pingel CLA 2012-06-30 12:44:51 EDT
From bug 382115:

(In reply to comment #13)
> (In reply to comment #12)
> > all records to be sorted chronologically.
> 
> Okay, no problem.
> 
> (In reply to comment #12)
> > I was however thinking that each build would be it's own row and
> > all records to be sorted chronologically. The goal being that if I submit a
> > change set I would see the build triggered by that in the row below intermixed
> > with comments on the task and code reviews etc.
> 
> Hm ... can you give me an example?

I was thinking that instead of showing "Eclipse Hudson" builds would be top-level nodes. So basically just removing the nesting and putting builds and change set on the same hierarchy level would already achieve what I have in mind.
Comment 11 Steffen Pingel CLA 2012-07-01 15:08:34 EDT
*** Bug 383153 has been marked as a duplicate of this bug. ***
Comment 12 Timur Achmetow CLA 2012-07-01 16:58:40 EDT
(In reply to comment #10)
> I was thinking that instead of showing "Eclipse Hudson" builds would be
> top-level nodes. So basically just removing the nesting and putting builds and
> change set on the same hierarchy level would already achieve what I have in
> mind.

Okay, that's no problem!
Comment 13 Timur Achmetow CLA 2012-07-02 17:24:12 EDT
(In reply to comment #10)
> I was thinking that instead of showing "Eclipse Hudson" builds would be
> top-level nodes. So basically just removing the nesting and putting builds and
> change set on the same hierarchy level would already achieve what I have in
> mind.

Implemented (s. screenshot).
Comment 14 Timur Achmetow CLA 2012-07-02 17:25:19 EDT
Created attachment 218186 [details]
changed hierarchy

builds now top-level nodes like changesets
Comment 15 Sam Davis CLA 2012-08-08 17:26:12 EDT
(In reply to comment #11)
> *** Bug 383153 has been marked as a duplicate of this bug. ***

I just created a Gerrit review which triggered 17 builds, meaning that I have 17 comments from Hudson telling me that a build was started, and may get 17 more telling me that they finished. This renders the comment stream basically useless. I think that this information should be displayed in the review not as a series of events (builds started and finished), but as a set of builds related to a patch set with their current status.
Comment 16 Timur Achmetow CLA 2012-08-09 17:42:05 EDT
(In reply to comment #15)
> I just created a Gerrit review which triggered 17 builds, meaning that I
> have 17 comments from Hudson telling me that a build was started, and may
> get 17 more telling me that they finished. This renders the comment stream
> basically useless. I think that this information should be displayed in the
> review not as a series of events (builds started and finished), but as a set
> of builds related to a patch set with their current status.

Thanks for the feedback Sam!

> I think that this information should be displayed in the
> review not as a series of events (builds started and finished), but as a set
> of builds related to a patch set with their current status.

Yes you are right, I think this makes sense.
Comment 17 Eclipse Webmaster CLA 2022-11-15 11:45:08 EST
Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub.

[1] https://github.com/orgs/eclipse-mylyn