Bugzilla – Full Text Bug Listing
| Summary: | test results sometimes do not get routed back to right download page summary | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Williams <david_williams> |
| Component: | Releng | Assignee: | David Williams <david_williams> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | daniel_megert |
| Version: | 4.2 | ||
| Target Milestone: | 4.3 M3 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
David Williams
FWIW, I can probably "manually" get results back to M20120905-2300 ... but, not until this afternoon, since I've several appointments and meeting till then. I have completed the initial design and code changes to fix this problem. Will try in tonight's (10/22) nightly build. In short, it now relies on a running cronjob (under committer id) to "check for data" and if found, to "get the zipped artifacts" from Hudson. The key is that "the data" is written at the end of the test job's completion, so there is perfect knowledge of what Hudson job (name and number) goes with which build (eclipseStream and buildId). For example, some data written to "testdata..." file might be ep4-unit-lin64 295 N20121021-0230 4.3.0 With those 4 pieces of data, we can retrieve the results, then do what ever we were doing before. The initial, root problem, after all, was we knew 3 pieces of that data, but just did not know the build number, for sure. In terms of mechanics, the new design/system invokes a final build step and it triggers a downstream job "ep-collectResults". It is a very simple job, being passed the data, and simply writing it to /shared/eclipse/sdk/testjobdata in files named "testjobdata<timestamp>.txt" such as testjobdata201210220658.txt, that has only those 4 pieces of data in it. It was done this way to have "the data" in a central place. In more detail, it is not actually good to write, from Hudson, to /shared ... at one point it was "disallowed" for a short time ... but, it seems that is pretty well entrenched and unlikely to change. But, if it does, then "the data" will at least be (or, could be) at one URL and a cron job could essentially get it from there, instead of a file system ... but that'd be wasteful and/or harder to do with "JSON APIs". So, the whole thing is a simple as keeping track of the exact data, instead of relying on "next build number" which might not be accurate by the time the job actually runs. All the associated scripts and tasks are still overly convoluted (so, some chance I've missed something), but I'm going to mark this as fixed and keep an eye on tonight's nightly. The cronjob has been running for a bit, and just detecting/reading the data files and echos what it reads without invoking "the work" script, but those have been used/tested independently a fair amount. This will be a much more efficient design where the only thing looping is the normal linux cronjobs (which it is made to do) ...and our code simply reacts to changes that are detected (or else does nothing). To correct some terminology, (now that I was setting up maintenance build test jobs) ... it is not actually a "final build step" that was added, but use of "Trigger parameterized build" which required a plugin of same name to be installed on the Hudson instance. mass change to 'verified', as these bugs are either routine or obviously fixed build breaks. |