Bug 92381 – Import the Android Test Runner scripts

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Peter Beverloo]

Import the Android Test Runner scripts

[Peter Beverloo]

Created attachment 154653 [details]
Patch

[WebKit Review Bot]

Attachment 154653 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Tools/ChangeLog', u'Tools/Scripts/webkitpy..." exit_code: 1
Tools/Scripts/webkitpy/thirdparty/android_testrunner/am_instrument_parser.py:34:  trailing whitespace  [pep8/W291] [5]
Tools/Scripts/webkitpy/thirdparty/android_testrunner/am_instrument_parser.py:69:  trailing whitespace  [pep8/W291] [5]
Tools/Scripts/webkitpy/thirdparty/android_testrunner/logger.py:67:  trailing whitespace  [pep8/W291] [5]
Tools/Scripts/webkitpy/thirdparty/android_testrunner/logger.py:86:  trailing whitespace  [pep8/W291] [5]
Tools/Scripts/webkitpy/thirdparty/android_testrunner/logger.py:91:  trailing whitespace  [pep8/W291] [5]
Total errors found: 5 in 9 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Peter Beverloo]

To keep the testing procedures independent of port-specific dependencies, import this suite. There are no local modifications, as the README file states.

Chromium uses these scripts as well. The webkitpy/common/android/ scripts will be more of a convenience wrapper around it, i.e. to get a list of devices (also for sharding) and handling common operations safely.

http://src.chromium.org/viewvc/chrome/trunk/src/third_party/android_testrunner/

[Adam Barth]

Comment on attachment 154653 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=154653&action=review

> Tools/Scripts/webkitpy/thirdparty/android_testrunner/LICENSE:4
> +                                 Apache License
> +                           Version 2.0, January 2004
> +                        http://www.apache.org/licenses/

I don't think the Apache license is allowed in WebKit.  We're allowed to use LGPL 2.1, BSD, and MIT (because MIT is essentially the same as BSD).

Typically when we want to use third party Python code that can't be stored in svn.webkit.org we use autoinstall to download the code on the client.

[Adam Barth]

It's also possible to use DEPS to bring in the code, but if we do that, we need to make sure that webkitpy continues to work for folks who don't have gclient installed.

[Peter Beverloo]

(In reply to comment #4)
> (From update of attachment 154653 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=154653&action=review
> 
> > Tools/Scripts/webkitpy/thirdparty/android_testrunner/LICENSE:4
> > +                                 Apache License
> > +                           Version 2.0, January 2004
> > +                        http://www.apache.org/licenses/
> 
> I don't think the Apache license is allowed in WebKit.  We're allowed to use LGPL 2.1, BSD, and MIT (because MIT is essentially the same as BSD).
> 
> Typically when we want to use third party Python code that can't be stored in svn.webkit.org we use autoinstall to download the code on the client.

I was unsure of the licensing issue. I asked Steve Block whether the licenses were compatible, which they seem to be, but this of course is independent of WebKit's regulations. I couldn't find a clear reference about our own licenses for third-party code.

I'll look into using autoinstall. Thank you for that suggestion. Using Chromium's DEPS for pulling in the Python code would mean that the Python code will be included in Source/WebKit/chromium/ (I don't think we should pull in port-specific DEPS in non-port specific directories). It actually already is available there as Source/WebKit/chromium/third_party/android_testrunner/.

The tricky thing there is, as you say, making sure that it also works with non-Chromium ports using this code. I'm not sure how we can achieve that, as this is critical in communicating with the device..

[Adam Barth]

> The tricky thing there is, as you say, making sure that it also works with non-Chromium ports using this code. I'm not sure how we can achieve that, as this is critical in communicating with the device..

If this is only going to be used by Chromium for now, we just need to make sure it doesn't break other webkitpy uses.

[Peter Beverloo]

(In reply to comment #7)
> > The tricky thing there is, as you say, making sure that it also works with non-Chromium ports using this code. I'm not sure how we can achieve that, as this is critical in communicating with the device..
> 
> If this is only going to be used by Chromium for now, we just need to make sure it doesn't break other webkitpy uses.

Ok. Closing this as invalid, we'll try a different approach.