Bug 67788 – Incorporate filter-build-webkit into build bots (EWS and regular)

• Status: NEW
• Component: Tools / Tests

[Matthew Delaney]

http://trac.webkit.org/changeset/94746 adds in a new script 'filter-build-webkit'

Once the script works well for you (https://bugs.webkit.org/show_bug.cgi?id=67787), it might be helpful to use it to filter the build output of the build bots to reduce the size of build logs and/or make the build logs more easily readable by others.

Currently, many bots' build logs are truncated (when viewed via the build waterfall page) because they're so long. Some say the full logs are useful, so I'm not proposing to get rid of them. I think that doing either of these two suggestions would be very helpful and easy to implement:

1) Change the build log output page to have the output of filter-build-webkit and a link to a separate page with the full output (i.e. the current page you see).
2) Modify the current build log output page to have the output of filter-build-webkit prepended to the current full (but often truncated) build log.

For quick reference:
Running 'build-webkit | filter-build-webkit --logfile FULL_LOG' will spit the output of build-webkit into FULL_LOG and the filtered output to stdout. Or you can add '-o FILTERED_LOG' to get the filtered output directly to a file.

[Eric Seidel (no email)]

It seems we should just wire this into build-webkit by default, and add a --no-filter option to turn it off for things that want the raw output.

[Matthew Delaney]

(In reply to comment #1)
> It seems we should just wire this into build-webkit by default, and add a --no-filter option to turn it off for things that want the raw output.

I totally agree. One reason I can think of to have it be a separate script is to parse/filter old build logs. So, perhaps we refactor out all the similar logic into something like: (https://bugs.webkit.org/show_bug.cgi?id=67753) and have both build-webkit and filter-build-webkit (which should really be named filter-build-ouput/log or something) use the refactored code.

[Eric Seidel (no email)]

I see no problem with it existing as a separate script.  I just don't think we should have to modify the bots to opt-in to this behavior. :)  It seems everyone (except perhaps some very strange cases) will want the filtered output.

Thanks for your work on this!

[Tony Chang]

Eric, this is the opposite of what you said 18 months ago:
  https://bugs.webkit.org/show_bug.cgi?id=35712#c6

I'd be curious to know what made you change your mind.

[Eric Seidel (no email)]

Quoting myself:

"So I like this change in principle.  But I think we may need to change the buildbots to call build-* with --verbose to satisify mark's concerns.  Also, it's sad that we continue to hack options in like this.  Would be better if (like python) we had some sort of option dictionary that we just passed around to all these methods.

r- because this woudl change buildbot behavior."

So I guess what's changed is that I agree that the bot output should change.  Others may not feel that way.

I r-'d probably mostly because of Mark Rowe's comment:
"Please don’t do this.  These message are necessary to track down certain classes of build errors."

I'm not sure I agree with Mark though.  I think such build errors are extremely rare.

[Mark Rowe (bdash)]

(In reply to comment #5)
> Quoting myself:
> 
> "So I like this change in principle.  But I think we may need to change the buildbots to call build-* with --verbose to satisify mark's concerns.  Also, it's sad that we continue to hack options in like this.  Would be better if (like python) we had some sort of option dictionary that we just passed around to all these methods.
> 
> r- because this woudl change buildbot behavior."
> 
> So I guess what's changed is that I agree that the bot output should change.  Others may not feel that way.

I don’t think any of this is relevant to the current proposal as it involves providing both the filtered and raw output.

> I r-'d probably mostly because of Mark Rowe's comment:
> "Please don’t do this.  These message are necessary to track down certain classes of build errors."
> 
> I'm not sure I agree with Mark though.  I think such build errors are extremely rare.

Perhaps you personally dealing with such build errors is extremely rare.  But again, none of this is particularly relevant to the current proposal.