Community
Participate
Working Groups
I can no longer find the console output logs, which contains output from the unit tests. For e.g. see here: http://download.eclipse.org/eclipse/downloads/drops/S-3.8M6-201203141800/logs.php#console The current one is empty as you can see here: http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M7-201205031800/logs.php#console
Just to document what I've done/found so far: I had to change the "logs.php" file a little, mostly cleanup, to not show chkpii section, and seemed that there was some "no op" code that was still looking for old test platforms which I removed. (will need to re-add, something, if/when we do "remote" testing on other hardware). But, the oddest thing, for some reason, given what I inherited or what I broke (or, both) I currently need to duplicate (by hand, copy) the console output in "testresults" and "testresults/consolelogs". It wasn't structured that way in the 3.8 M6 directories, so I'm not sure exactly how its supposed to work or what's missing, but will continue to investigate streamlining and automating. Plus, if easy to do, I feel compelled to put "file size" in parentheses after each console file link, since some of them are truly empty, but when you click on an empty one, you just see a blank page, so there's some uncertainty if it's really "no output" (which is the case for all "blanks", as far as I know) or if the link is broken or something. So, if easy. We do that lots of other places. The "process" is complicated (whether by hand, or once automated) by the fact that we are running as e4Build user as the results "come back" from hudson (we actually, "spin" looking for them every 10 minutes), we unzip the results into (nearly) the right place (but don't duplicate, as for some reason seems required ... I'm sure not exactly required) ... but, then (currently) need to run "by hand", under e4Build id, an "update pages" script which "fixes up" many of the download pages links and "status". [would be nice to avoid all this in future]. But then, the complication I'm wordily trying to describe :) is to get those results up to download server, I need to re-run a promotion script under my committer id. So, plenty of room for future improvements :)
(In reply to comment #1) > But then, the complication I'm wordily trying to describe :) is to get those > results up to download server, I need to re-run a promotion script under my > committer id. I don't understand what's special about the console logs. We are seeing all the test results in the download directory, so clearly *some* information from the tests is being promoted to downloads. Wouldn't the console log from the test run be "just another file" next to the test result files and be promoted in the same way?
(In reply to comment #2) > (In reply to comment #1) > > But then, the complication I'm wordily trying to describe :) is to get those > > results up to download server, I need to re-run a promotion script under my > > committer id. > > I don't understand what's special about the console logs. We are seeing all the > test results in the download directory, so clearly *some* information from the > tests is being promoted to downloads. Wouldn't the console log from the test > run be "just another file" next to the test result files and be promoted in the > same way? Not sure if you are asking about the "promotion" (I just meant that, in general, there's a script that creates new "pages" after the test results come back and those need to uploaded (console logs or not). But, yes, the console logs have always been there (as long as we've had results) just not "linked" in, anywhere. As an experiment, today I tried just creating an empty subdirectory under 'consolelogs', with the right name, testresults/consolelogs/win32.win32.x86_7.0 even though its empty the reports actually under /testresults/win32.win32.x86_7.0 are linked in. Not sure if that's from the "report generator" end of things, or the PHP page logic, but, somewhat reassuring, somehow. That subdirectory testresults/consolelogs/win32.win32.x86_7.0 used to (in M6) have some "longer" logs in it so guess it was just taken as an "indicator" to link in the individual logs (and, no idea why we aren't getting the longer logs ... I _think_ they are are "just" a continuous log kept while all tests run (and, I know from my WTP days, it can contain useful info not in the individual logs, such as if a test is "not found" or if the test itself times out).
I think this is working now, but honestly, I'm not sure which of several things was the true "fix". I've discovered I do NOT need to create the estresults/consolelogs/win32.win32.x86_7.0 directory to get them to display ... my best guess is some of the earlier failures were either permission problems on the server, or the "logs.php" had some error in it, that was fixed coincidentally.
Looks good to me.
