| Summary: | [activity] extend the TreeViewer for additional build data | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Timur Achmetow <achmetow84> | ||||||||||
| Component: | Mylyn | Assignee: | 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
Timur Achmetow
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? Created attachment 217723 [details]
test results from the build editor
You mean like the data in the screenshot?
Created attachment 217725 [details]
builds view
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. Okay I understand; you want to show the whole content from the builds view? 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? (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 ... ?? contributions are here: https://git.eclipse.org/r/#/c/6545/ more details here: http://wiki.eclipse.org/Mylyn/Activity_Tracing_For_Mylyn 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
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. *** Bug 383153 has been marked as a duplicate of this bug. *** (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! (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). Created attachment 218186 [details]
changed hierarchy
builds now top-level nodes like changesets
(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. (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. 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 |