Summary: | [Win] Switch build to MSBuild so we get more useful stdout logging in our buildbot infrastructure | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brent Fulgham <bfulgham> | ||||
Component: | Tools / Tests | Assignee: | Brent Fulgham <bfulgham> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | ap, bfulgham, commit-queue, darin, dbates, ddkilzer | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | All | ||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=140819 | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 142360 | ||||||
Attachments: |
|
Description
Brent Fulgham
2015-01-23 16:07:18 PST
I spent some time playing with this last night, and found a few useful things: 1. MSBuild output appears to go to stdout, so we might be able to remove the Windows-specific build timeout we were using to avoid false build failures. 2. MSBuild accepts an input flag "/verbosity", which can be set to "minimal". When I do so, we get very concise logging, that only shows files that were built and any errors or warnings. All the other cruft is missing. 3. MSBuild is perfectly happy running with out existing Solutions. So there is very little effort to turn this on, and very little harm in reverting to our old way if we encounter problems. Once I confirm proper build behavior locally (in the next hour or so), I will propose a patch to switch to MSBuild. Created attachment 247967 [details]
Patch
This patch may not work on EWS without rebooting those bots. It looks like the existing MSBuild processes triggered by the build loop are locking the log file we attempt to write. Comment on attachment 247967 [details]
Patch
r=me
Committed r181092: <http://trac.webkit.org/changeset/181092> I'm noticing this in the logs: TestWebKitAPI.vcxproj -> C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\bin32\TestWebKitAPI.exe C:\cygwin\home\buildbot\slave\win-release\build\WebKitBuild\Release\BuildOutput.htm The process cannot access the file because it is being used by another process. The process cannot access the file because it is being used by another process. I think the AssembleBuildLogs command is trying to grab old log files and add them to the new BuildOutput.html. However, this is locked by MSBuild (since that is the output file it generates). I may need to clean up the build machines to get rid of this warning message. The EWS bots are failing because MSBuild wants the build output directory to exist at launch so that it can immediately start writing logs. Visual Studio was apparently happy starting up, creating any directories it needed, then starting logging as part of a pre-build step. I need to revise the Windows build logic to make sure the build target directory exists at the time we trigger MSBuild. |