Bugzilla – Full Text Bug Listing
| Summary: | Improve interaction between upstream and downstream builds | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Kiryl Kazakevich <kiryl.kazakevich> | ||||
| Component: | TPTP | Assignee: | Kiryl Kazakevich <kiryl.kazakevich> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P1 | CC: | analexee, chris.l.elford, igor.alelekov, jcayne, jkubasta, paulslau | ||||
| Version: | unspecified | Keywords: | plan | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| URL: | http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_200351.html | ||||||
| Whiteboard: | closed460, bvt | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 211751 | ||||||
| Attachments: |
|
||||||
|
Description
Kiryl Kazakevich
Created attachment 80665 [details]
Feature Description Document
This enhancement not requested/AG reviewed/AG approved for 4.5. Approved by the AG for TPTP 4.5 with the following comments: -This is definitely need to streamline our build process. -What is the design of this solution? This Description Document requires more design content before this enhancement can proceed -Will Intel be contributing to this enhancement? Hi Joel, This is my current view of the enhancement: - develop a request system so upstream part can request downstream part to do some actions - requests must be served in reasonable time (say up to 5 minutes) - actions to request are: 1) start build 2) get build status 3) stop build 4) get build logs Currently TPTP build system allows actions (1) and (2). Action (1) is requested by upstream by creating a new subdirectory with TPTP driver to build at dev.eclipse.org. Downstream polls dev.eclipse.org every 2-3-4 hours (it depends on current loading of downstream build boxes), downloads necessary parts of the driver, completes build, uploads results. The problem here is response time: not 5 minutes, but up to hours. Action (2) is done automatically for every build through .status file located at dev.eclipse.org in the TPTP drive directory which is built now. Downstream updates this file during building with the build status. Currently only two events are reported: build started, build completed. My proposal is to work on this enhancement in two stages. On the stage one I propose to improve implementations of the actions (1) and (2): 1) decrease reaction time to minutes 2) add more events into .status (at least which component is built now) On the stage two we need design and implement some type of the system which allows upstream to send requests to downstream, and implement all (1)-(4) actions through this system. I have no ideas now what this system can be. In the past I though about mail to send requests and receive responses. It may be problematic from the IT point of view. I think we should use the chanel we already have: dev.eclipse.org host accessible both by upstream and downstream through ssh connection. Work for the stage one is to be done by me as it related to downstream build scripts. If you agree with foresaid, please reassign the bug to me, and I will start working. Thanks, Kiryl I think this is a good plan to begin by increasing the build frequency with which we can start builds. For the .status file, can we add the last error should the build fail. This would provide some information as to why the build is taking longer than normal should we not see a line saying the build has completed. If the build fails, would action 3 provide us the ability to stop and restart (using action 1) the build again to try for another good build? For example, if the CVS was not responding during the first build attempt. For action 4, putting a copy of the logs to dev.eclipse.org would be the best solution. We may want to explore also outputting the information from the .status file also to an XML or HTML format so that others have the ability to view the status of a build if they are waiting on one to complete. I look forward to seeing the progress of stage one. Current status: implementation is finished. It includes: 1) quick response on new upstream build 2) detailed real-time downstream build status on dev.eclipse.org 3) upload downstream build master log and build boxes logs The enhancement is under heavy testing. Going to be resolved in a day. Checked in to HEAD. Downstream build scripts are moved to master/bash/downstream subdirectory. Main script is main.sh. Previous build scripts build_ia.sh rmt*.sh are now obsolete. The only feature discussed here but not implemented is remote stop of downstream build. I would like to close this bugzilla in current state. If the "stop" feature is important, we can reopen this bugzilla or create new one. Resolve as fixed As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |