Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2551803003:
[Cronet] Add cronet_test_package build target (Closed)
|
Created:
4 years ago by pauljensen Modified:
4 years ago CC:
chromium-reviews, cbentzel+watch_chromium.org Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
Description[Cronet] Add cronet_test_package build target
This target packages up all that is needed to run Cronte tests.
BUG=629299
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester
Committed: https://crrev.com/eafdede4e31382c6d80d5500416fdda967ae5b74
Cr-Commit-Position: refs/heads/master@{#439016}
Patch Set 1 #Patch Set 2 : add assets #Patch Set 3 : add test files #Patch Set 4 : fixes #Patch Set 5 : make subdirectory of cronet/ #
Total comments: 18
Patch Set 6 : address comments #Patch Set 7 : put netty jar path in gni file #
Total comments: 4
Patch Set 8 : netty typo #Patch Set 9 : symc #
Messages
Total messages: 33 (11 generated)
Description was changed from ========== [Cronet] Add cronet_test_package build target This target packages up all that is needed to run Cronte tests, with the exception of the netty-tcnative shared object so BidirectionalStream tests cannot be run for now. BUG=629299 ========== to ========== [Cronet] Add cronet_test_package build target This target packages up all that is needed to run Cronte tests, with the exception of the netty-tcnative shared object so BidirectionalStream tests cannot be run for now. BUG=629299 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester ==========
Description was changed from ========== [Cronet] Add cronet_test_package build target This target packages up all that is needed to run Cronte tests, with the exception of the netty-tcnative shared object so BidirectionalStream tests cannot be run for now. BUG=629299 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester ========== to ========== [Cronet] Add cronet_test_package build target This target packages up all that is needed to run Cronte tests. BUG=629299 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester ==========
pauljensen@chromium.org changed reviewers: + mef@chromium.org
Misha, PTAL, thank you!
On 2016/12/13 14:47:41, pauljensen wrote: > Misha, PTAL, thank you! Why would we want to have it packaged separately? Would it make sense to add tests subtarget to cronet_package target so everything is still uploaded into same combined output folder?
On 2016/12/13 20:50:45, mef wrote: > Why would we want to have it packaged separately? > Would it make sense to add tests subtarget to cronet_package target so > everything is still uploaded into same combined output folder? SGTM, done. This will save me making a CL to have the bots build and upload the new targets. The one quirk is that cronet_package has to be marked testonly as it now depends on test stuff, but this should be okay as it's not really depended on by other targets. I made a couple other tweaks: 1. put apks in apks subdirectory 2. fix a little race by adding a dependency
Friendly ping; be great to land this before break.
mef@chromium.org changed reviewers: + jbudorick@chromium.org
+jbudorick to advice on referencing files from dependencies and other advanced gn magic. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... File components/cronet/android/BUILD.gn (right): https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:869: "//third_party/netty4/src/jar/all-in-one/netty-all-4.1.0.CR1-20160111.120759-50.jar", This seems very fragile. I wonder whether there is a way to get the list of jars from "//third_party/netty4:netty_all_java" target. Adding jbudorick to comment. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1158: copy("cronet_package_copy_native_test_lib") { I wonder whether we need stripped native test lib at all. The goal is to use it for testing, and unstripped seems like a proper target. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1176: "$root_out_dir/lib.unstripped/libcronet_tests.so", based on the comment above, would we ever need to manually symbolicate test crash if test app used unstripped native library? https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1201: "$root_out_dir/apks/ChromiumNetTestSupport.apk", Interesting. Maybe add comment that this provides EmbeddedTestServer? https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1204: "$_test_package_dir/apks/${android_app_abi}/{{source_file_part}}", kudos for including abi into output path. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1285: if (!(target_cpu == "arm" && arm_version == 7) || !arm_use_neon) { Do we really need to enforce it here? What exactly would fail if these conditions are not met? Also, should we limit a set of arch+config configurations for which we create cronet_test_package? I doubt that we'll run those tests for MIPS, for example.
https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... File components/cronet/android/BUILD.gn (right): https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:869: "//third_party/netty4/src/jar/all-in-one/netty-all-4.1.0.CR1-20160111.120759-50.jar", On 2016/12/14 23:04:51, mef wrote: > This seems very fragile. > I wonder whether there is a way to get the list of jars from > "//third_party/netty4:netty_all_java" target. > Adding jbudorick to comment. Ya, I agree it's fragile. I showed it to Andrei last week and complained it was fragile but I'm not sure either of us had a good idea to improve it. In Blaze you can specify targets by name as sources of genrules...but not in GN. I imagine we could do something like write a "template" that accesses the jar paths but that might be a lot of work for this. Another alternative would be to have a gypi file that exposes the jar path, like net.gypi. For now I don't think this will be a significant amount of work to maintain, and am okay punting doing something smarter until later. If there's a simple and easy solution I can give that a shot. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1158: copy("cronet_package_copy_native_test_lib") { On 2016/12/14 23:04:51, mef wrote: > I wonder whether we need stripped native test lib at all. > The goal is to use it for testing, and unstripped seems like a proper target. libcronet_tests.so unstripped is more than 100 MB bigger than libcronet_tests.so stripped, so I imagine using the unstripped one would make our testing quite slow as installing large APKs on emulators can take several minutes, which is significant because running our tests takes several minutes. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1176: "$root_out_dir/lib.unstripped/libcronet_tests.so", On 2016/12/14 23:04:51, mef wrote: > based on the comment above, would we ever need to manually symbolicate test > crash if test app used unstripped native library? The crash handler could probably symbolicate if we used unstrupped native libraries, but as I said above, I think it would slow our testing down significantly to download and install the larger APKs. I'd rather not slow down the common case of running the tests to speed up the rare case of wanting to symbolicate. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1201: "$root_out_dir/apks/ChromiumNetTestSupport.apk", On 2016/12/14 23:04:51, mef wrote: > Interesting. Maybe add comment that this provides EmbeddedTestServer? Done. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1204: "$_test_package_dir/apks/${android_app_abi}/{{source_file_part}}", On 2016/12/14 23:04:51, mef wrote: > kudos for including abi into output path. Acknowledged. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1285: if (!(target_cpu == "arm" && arm_version == 7) || !arm_use_neon) { On 2016/12/14 23:04:51, mef wrote: > Do we really need to enforce it here? No, removed. > What exactly would fail if these conditions are not met? The check in cronet_package should prevent any failures. > Also, should we limit a set of arch+config configurations for which we create > cronet_test_package? > I doubt that we'll run those tests for MIPS, for example. I changed it to avoided MIPS, where we don't test.
https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... File components/cronet/android/BUILD.gn (right): https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:869: "//third_party/netty4/src/jar/all-in-one/netty-all-4.1.0.CR1-20160111.120759-50.jar", On 2016/12/15 04:08:34, pauljensen wrote: > On 2016/12/14 23:04:51, mef wrote: > > This seems very fragile. > > I wonder whether there is a way to get the list of jars from > > "//third_party/netty4:netty_all_java" target. > > Adding jbudorick to comment. > > Ya, I agree it's fragile. I showed it to Andrei last week and complained it was > fragile but I'm not sure either of us had a good idea to improve it. In Blaze > you can specify targets by name as sources of genrules...but not in GN. I > imagine we could do something like write a "template" that accesses the jar > paths but that might be a lot of work for this. Another alternative would be to > have a gypi file that exposes the jar path, like net.gypi. For now I don't > think this will be a significant amount of work to maintain, and am okay punting > doing something smarter until later. If there's a simple and easy solution I > can give that a shot. Yeah, per our offline conversation, adding something like //third_party/netty4/netty.gni would make it less fragile. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1158: copy("cronet_package_copy_native_test_lib") { On 2016/12/15 04:08:35, pauljensen wrote: > On 2016/12/14 23:04:51, mef wrote: > > I wonder whether we need stripped native test lib at all. > > The goal is to use it for testing, and unstripped seems like a proper target. > > libcronet_tests.so unstripped is more than 100 MB bigger than libcronet_tests.so > stripped, so I imagine using the unstripped one would make our testing quite > slow as installing large APKs on emulators can take several minutes, which is > significant because running our tests takes several minutes. Acknowledged. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1176: "$root_out_dir/lib.unstripped/libcronet_tests.so", On 2016/12/15 04:08:35, pauljensen wrote: > On 2016/12/14 23:04:51, mef wrote: > > based on the comment above, would we ever need to manually symbolicate test > > crash if test app used unstripped native library? > > The crash handler could probably symbolicate if we used unstrupped native > libraries, but as I said above, I think it would slow our testing down > significantly to download and install the larger APKs. I'd rather not slow down > the common case of running the tests to speed up the rare case of wanting to > symbolicate. Acknowledged.
https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... File components/cronet/android/BUILD.gn (right): https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:869: "//third_party/netty4/src/jar/all-in-one/netty-all-4.1.0.CR1-20160111.120759-50.jar", On 2016/12/15 04:08:34, pauljensen wrote: > On 2016/12/14 23:04:51, mef wrote: > > This seems very fragile. > > I wonder whether there is a way to get the list of jars from > > "//third_party/netty4:netty_all_java" target. > > Adding jbudorick to comment. > > Ya, I agree it's fragile. I showed it to Andrei last week and complained it was > fragile but I'm not sure either of us had a good idea to improve it. In Blaze > you can specify targets by name as sources of genrules...but not in GN. I > imagine we could do something like write a "template" that accesses the jar > paths but that might be a lot of work for this. Another alternative would be to > have a gypi file that exposes the jar path, like net.gypi. For now I don't > think this will be a significant amount of work to maintain, and am okay punting > doing something smarter until later. If there's a simple and easy solution I > can give that a shot. We've used .build_config files for stuff like this elsewhere. I think you'd want something like: "@FileArg(//third_party/netty4:netty_all_java__build_config:deps_info:jar_path)" I think you could do something like this for all of the above jars. https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:1158: copy("cronet_package_copy_native_test_lib") { On 2016/12/15 04:08:35, pauljensen wrote: > On 2016/12/14 23:04:51, mef wrote: > > I wonder whether we need stripped native test lib at all. > > The goal is to use it for testing, and unstripped seems like a proper target. > > libcronet_tests.so unstripped is more than 100 MB bigger than libcronet_tests.so > stripped, so I imagine using the unstripped one would make our testing quite > slow as installing large APKs on emulators can take several minutes, which is > significant because running our tests takes several minutes. This is something we're currently wrestling with for the rest of our android native tests, too.
https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... File components/cronet/android/BUILD.gn (right): https://codereview.chromium.org/2551803003/diff/80001/components/cronet/andro... components/cronet/android/BUILD.gn:869: "//third_party/netty4/src/jar/all-in-one/netty-all-4.1.0.CR1-20160111.120759-50.jar", On 2016/12/15 18:19:34, jbudorick wrote: > On 2016/12/15 04:08:34, pauljensen wrote: > > On 2016/12/14 23:04:51, mef wrote: > > > This seems very fragile. > > > I wonder whether there is a way to get the list of jars from > > > "//third_party/netty4:netty_all_java" target. > > > Adding jbudorick to comment. > > > > Ya, I agree it's fragile. I showed it to Andrei last week and complained it > was > > fragile but I'm not sure either of us had a good idea to improve it. In Blaze > > you can specify targets by name as sources of genrules...but not in GN. I > > imagine we could do something like write a "template" that accesses the jar > > paths but that might be a lot of work for this. Another alternative would be > to > > have a gypi file that exposes the jar path, like net.gypi. For now I don't > > think this will be a significant amount of work to maintain, and am okay > punting > > doing something smarter until later. If there's a simple and easy solution I > > can give that a shot. > > We've used .build_config files for stuff like this elsewhere. I think you'd want > something like: > > "@FileArg(//third_party/netty4:netty_all_java__build_config:deps_info:jar_path)" > > I think you could do something like this for all of the above jars. I tried that and just got: ninja: error: '../../components/cronet/android/@FileArg(/third_party/netty4:netty_all_java__build_config:deps_info:jar_path)', needed by 'obj/components/cronet/android/extract_cronet_test_jars.inputdeps.stamp', missing and no known rule to make it
This lgtm, but if @FileArg can simplify it, then I'm all for it (I can't find a doc or simple example for @FileArg usage). https://codereview.chromium.org/2551803003/diff/120001/third_party/netty4/net... File third_party/netty4/netty4.gni (right): https://codereview.chromium.org/2551803003/diff/120001/third_party/netty4/net... third_party/netty4/netty4.gni:5: # Defines location of nett4 jar file. nit: netty4
https://codereview.chromium.org/2551803003/diff/120001/third_party/netty4/net... File third_party/netty4/netty4.gni (right): https://codereview.chromium.org/2551803003/diff/120001/third_party/netty4/net... third_party/netty4/netty4.gni:5: # Defines location of nett4 jar file. On 2016/12/15 19:22:27, mef wrote: > nit: netty4 Done.
On 2016/12/15 19:22:27, mef wrote: > This lgtm, but if @FileArg can simplify it, then I'm all for it (I can't find a > doc or simple example for @FileArg usage). Experimenting a bit, I'll get back to you within the hour. > > https://codereview.chromium.org/2551803003/diff/120001/third_party/netty4/net... > File third_party/netty4/netty4.gni (right): > > https://codereview.chromium.org/2551803003/diff/120001/third_party/netty4/net... > third_party/netty4/netty4.gni:5: # Defines location of nett4 jar file. > nit: netty4
https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... File components/cronet/android/BUILD.gn (right): https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... components/cronet/android/BUILD.gn:861: sources = [ So you *could* do this with FileArg, but you'd need to rework this a bit: - remove sources and _rebased_sources - move deps up before args - add something like this: _jars = [] foreach(_jar_target, deps) { _build_config = get_label_info(_jar_target, "target_gen_dir") + "/" + get_label_info(_jar_target, "name") + ".build_config" _rebased_build_config = rebase_path(_build_config, root_build_dir) _jars += [ "@FileArg($_rebased_build_config:deps_info:jar_path)" ] } - switch _rebased_sources in args to _jars - add build_utils.ExpandFileArgs to extract_from_jars.py. You would have to do this on the list returned by build_utils.ParseGnList (https://codesearch.chromium.org/chromium/src/components/cronet/tools/extract_...) before iterating over it. If you're going to this length anyway, I'd probably also make a template for extract_from_jars to share code w/ extract_cronet_jars.
https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... File components/cronet/android/BUILD.gn (right): https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... components/cronet/android/BUILD.gn:861: sources = [ On 2016/12/15 19:59:32, jbudorick wrote: > So you *could* do this with FileArg, but you'd need to rework this a bit: > - remove sources and _rebased_sources > - move deps up before args > - add something like this: > > _jars = [] > foreach(_jar_target, deps) { > _build_config = > get_label_info(_jar_target, "target_gen_dir") + "/" + > get_label_info(_jar_target, "name") + ".build_config" > _rebased_build_config = rebase_path(_build_config, root_build_dir) > _jars += [ "@FileArg($_rebased_build_config:deps_info:jar_path)" ] > } > > - switch _rebased_sources in args to _jars > - add build_utils.ExpandFileArgs to extract_from_jars.py. You would have to do > this on the list returned by build_utils.ParseGnList > (https://codesearch.chromium.org/chromium/src/components/cronet/tools/extract_...) > before iterating over it. > > If you're going to this length anyway, I'd probably also make a template for > extract_from_jars to share code w/ extract_cronet_jars. Do android_library target's have jar_path or is this only going to work for java_imports?
On 2016/12/15 20:58:09, pauljensen wrote: > https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... > File components/cronet/android/BUILD.gn (right): > > https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... > components/cronet/android/BUILD.gn:861: sources = [ > On 2016/12/15 19:59:32, jbudorick wrote: > > So you *could* do this with FileArg, but you'd need to rework this a bit: > > - remove sources and _rebased_sources > > - move deps up before args > > - add something like this: > > > > _jars = [] > > foreach(_jar_target, deps) { > > _build_config = > > get_label_info(_jar_target, "target_gen_dir") + "/" + > > get_label_info(_jar_target, "name") + ".build_config" > > _rebased_build_config = rebase_path(_build_config, root_build_dir) > > _jars += [ "@FileArg($_rebased_build_config:deps_info:jar_path)" ] > > } > > > > - switch _rebased_sources in args to _jars > > - add build_utils.ExpandFileArgs to extract_from_jars.py. You would have to > do > > this on the list returned by build_utils.ParseGnList > > > (https://codesearch.chromium.org/chromium/src/components/cronet/tools/extract_...) > > before iterating over it. > > > > If you're going to this length anyway, I'd probably also make a template for > > extract_from_jars to share code w/ extract_cronet_jars. > > Do android_library target's have jar_path or is this only going to work for > java_imports? This seems rather complicated, I think I'll just land the current patch set as is. We can change to the new method if we can figure it out later.
On 2016/12/15 22:36:37, pauljensen wrote: > On 2016/12/15 20:58:09, pauljensen wrote: > > > https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... > > File components/cronet/android/BUILD.gn (right): > > > > > https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... > > components/cronet/android/BUILD.gn:861: sources = [ > > On 2016/12/15 19:59:32, jbudorick wrote: > > > So you *could* do this with FileArg, but you'd need to rework this a bit: > > > - remove sources and _rebased_sources > > > - move deps up before args > > > - add something like this: > > > > > > _jars = [] > > > foreach(_jar_target, deps) { > > > _build_config = > > > get_label_info(_jar_target, "target_gen_dir") + "/" + > > > get_label_info(_jar_target, "name") + ".build_config" > > > _rebased_build_config = rebase_path(_build_config, root_build_dir) > > > _jars += [ "@FileArg($_rebased_build_config:deps_info:jar_path)" ] > > > } > > > > > > - switch _rebased_sources in args to _jars > > > - add build_utils.ExpandFileArgs to extract_from_jars.py. You would have > to > > do > > > this on the list returned by build_utils.ParseGnList > > > > > > (https://codesearch.chromium.org/chromium/src/components/cronet/tools/extract_...) > > > before iterating over it. > > > > > > If you're going to this length anyway, I'd probably also make a template for > > > extract_from_jars to share code w/ extract_cronet_jars. > > > > Do android_library target's have jar_path or is this only going to work for > > java_imports? > > This seems rather complicated, I think I'll just land the current patch set as > is. We can change to the new method if we can figure it out later. sgtm, lgtm
The CQ bit was checked by pauljensen@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: ios-device on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...) ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...) ios-simulator on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...) ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
On 2016/12/15 20:58:09, pauljensen wrote: > https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... > File components/cronet/android/BUILD.gn (right): > > https://codereview.chromium.org/2551803003/diff/120001/components/cronet/andr... > components/cronet/android/BUILD.gn:861: sources = [ > On 2016/12/15 19:59:32, jbudorick wrote: > > So you *could* do this with FileArg, but you'd need to rework this a bit: > > - remove sources and _rebased_sources > > - move deps up before args > > - add something like this: > > > > _jars = [] > > foreach(_jar_target, deps) { > > _build_config = > > get_label_info(_jar_target, "target_gen_dir") + "/" + > > get_label_info(_jar_target, "name") + ".build_config" > > _rebased_build_config = rebase_path(_build_config, root_build_dir) > > _jars += [ "@FileArg($_rebased_build_config:deps_info:jar_path)" ] > > } > > > > - switch _rebased_sources in args to _jars > > - add build_utils.ExpandFileArgs to extract_from_jars.py. You would have to > do > > this on the list returned by build_utils.ParseGnList > > > (https://codesearch.chromium.org/chromium/src/components/cronet/tools/extract_...) > > before iterating over it. > > > > If you're going to this length anyway, I'd probably also make a template for > > extract_from_jars to share code w/ extract_cronet_jars. > > Do android_library target's have jar_path or is this only going to work for > java_imports? They do.
The CQ bit was checked by pauljensen@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from mef@chromium.org Link to the patchset: https://codereview.chromium.org/2551803003/#ps160001 (title: "symc")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 160001, "attempt_start_ts": 1481847973706280,
"parent_rev": "9c622ecc158bbc4b3be86497a153d0ec1900076f", "commit_rev":
"1ee513d2e7b71f24d48bfd21de369a6301184854"}
Message was sent while issue was closed.
Description was changed from ========== [Cronet] Add cronet_test_package build target This target packages up all that is needed to run Cronte tests. BUG=629299 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester ========== to ========== [Cronet] Add cronet_test_package build target This target packages up all that is needed to run Cronte tests. BUG=629299 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester Review-Url: https://codereview.chromium.org/2551803003 ==========
Message was sent while issue was closed.
Committed patchset #9 (id:160001)
Message was sent while issue was closed.
Description was changed from ========== [Cronet] Add cronet_test_package build target This target packages up all that is needed to run Cronte tests. BUG=629299 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester Review-Url: https://codereview.chromium.org/2551803003 ========== to ========== [Cronet] Add cronet_test_package build target This target packages up all that is needed to run Cronte tests. BUG=629299 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester Committed: https://crrev.com/eafdede4e31382c6d80d5500416fdda967ae5b74 Cr-Commit-Position: refs/heads/master@{#439016} ==========
Message was sent while issue was closed.
Patchset 9 (id:??) landed as https://crrev.com/eafdede4e31382c6d80d5500416fdda967ae5b74 Cr-Commit-Position: refs/heads/master@{#439016} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
