Also set xcode back to xcode 13 for iOS 14.
Change-Id: Ic5475d274895b5f86e4fea36805dec4486adc79b
Bug: b/264630045
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290894
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39094}
The goal of this bot is to replace ios_sim_x64_dbg_ios(12, 13 and 14).
Change-Id: I6d8f5004a9440f5fd8cb96730dc2dbb4abba2e61
Bug: b/264630045
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290893
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39086}
Also add "--xctest" cause I suspect this is what causes the current errors.
Change-Id: I541de48722bfea6dcf372e7155a9ea033e207c4f
Bug: b/262490083
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/290579
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39020}
When running Gtest-based tests, we use the WebRtcUnitTestDelegate
to call Gtest from the iOS application.
However, if tests take too long, iOS terminates that application.
The test execution code (ios/build/bots/scripts) retries up to three times,
but that functionality doesn't seem to work lately.
Because of this, module_unittests are failing at a fairly high rate.
Instead, use GoogleTestRunner to let XCTest run Gtest-based tests.
This is enabled with the --enable-run-ios-unittests-with-xctest flag,
which is passed when using the --xctest flag in ios/build/bots/scripts/run.py.
Existing XCTest-based tests (eg. sdk_unittest) are not affected
as the --xcode-parallelization flag takes precedence over --xctest.
Bug: None
Change-Id: Ib7f8a6d24f6b25444a47e3a83c0edbe96318be46
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/287180
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#38859}
Fixing errors like this:
Evaluation of CheckChangeOnCommit failed: can only concatenate str (not "list") to str, Traceback (most recent call last):
...
File "/path/to/webrtc/src/infra/specs/PRESUBMIT.py", line 31, in CheckPatchFormatted
results.append(output_api.PresubmitError('Error calling "' + cmd + '"'))
TypeError: can only concatenate str (not "list") to str
Bug: None
Change-Id: Ia0b1c7a80a2752934c02d932a9206114769bcaa1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/286547
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38831}
This is required to compile the default target in Android bots.
Bug: webrtc:14743
Change-Id: Ib8248e3d874b45eb59283f9503e07eadcd53bad7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/286545
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38830}
Also apply the formatting to the .pyl files.
Change-Id: I5dc668b53570d042862d2de5948b72d1cf6d31b3
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285941
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#38797}
Currently the tests are running only on Windows x86 Release.
* Windows capture_tests are moved to run on x64.
* win_x64_clang_dbg_win10 is removed because it's a duplicate of * win_x64_clang_dbg.
Change-Id: Ibf4db1d1749aa31d665ad30825e9dcfef6910be4
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285540
Reviewed-by: Christoffer Jansson <jansson@google.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38772}
* Add '--quick' argument to 'low_bandwidth_audio_test' even though it doesn't look like it makes much timing difference.
* Add sharding for 'svc_tests' and 'video_engine_tests'.
Change-Id: I6e3357954d18ad03ea9f62912dd77e0e1a74b97d
Bug: webrtc:14713
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/285100
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#38748}
The expected behavior is to have something similar than python:
https://docs.python.org/dev/library/argparse.html#dest:
"Any internal - characters will be converted to _ characters to make sure the string is a valid attribute name".
This allows to catch chromium arguments like 'isolated-script-test-output' that previously needed some preprocessing done for example in flags_compatibility.py.
This CL also fixes a fuchsia specific issue where the test runner needs a 'isolated-script-test-output' argument but then pass the argument to WebRTC that expects a 'isolated_script_test_output' argument. Thus calling flags_compatibility before the test_runner fails and there is not much room to change the argument in between the test runner and the test.
Change-Id: I48a591743fa50484a0ec584a3f9e97d9e0fd25ef
Bug: webrtc:14694
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/284541
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38707}
This makes it easier to update devices in th e future (avoiding multiple
CLs to change names, etc..).
Bug: b/259076774
Change-Id: I20ae940823978fbae84495d266345e4990184130
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283720
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38650}
* Use the same logdog_butler as Chromium instead of redefining one.
* Use luci-auth to prevent "local auth - HTTP 400" errors.
Change-Id: I2a0d1393f9f0e1e41b2bcc9a9fec2c50c19675f3
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283520
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#38637}
Add a few tests to get started on debugging.
The goal of this CL is to get the Fuchsia bots running the tests without infra specific issues. After landing this, failures will be in test framework files (e.g. test/testsupport folder) and WebRTC code.
Bug: b/232740856
Change-Id: I332607fe875334769e7dadf6696d878a23a7e69f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280440
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@google.com>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#38596}
This CL will also make PipeWire tests retried 3 times in case of failures.
Change-Id: I9c66351f7ee171e29266fe4b8dcd52ca282c8f6d
Bug: webrtc:14644
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282820
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38595}
This flag is passed by default in chromium after https://crrev.com/c/3953676
Bug: b/257915522
Change-Id: If3518fa86f3e05ad02bfad8f200b17958f78602d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282225
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@google.com>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Auto-Submit: Andrey Logvin <landrey@google.com>
Cr-Commit-Position: refs/heads/main@{#38581}
This test created another PipeWire stream we can connect to with
SharedScreenCastStream and recieve frames from there. This is an
initial version, where I test whether we can successfuly connect
and disconnect, receive frames and it also tests DesktopFrameQueue.
In the future I will add tests to test mouse cursor and try to
come up with some corner cases and possible scenarios.
Bug: webrtc:13429
Change-Id: Ib2a749207085c6324ffe3d5cc8f2f9c631fa6459
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256267
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38431}
This reverts commit dd32562f242b247aed8add4efecaf3e20c623b9a.
Reason for revert: Updated the original change to dynamically load
the CoreMessaging.dll instead of statically linking with the .lib.
Original change's description:
> Revert "Wait for frames to arrive in WgcCapturer instead of returning nothing."
>
> This reverts commit 93bb3051490253d56dc1cdab4701b91138a151c3.
>
> Reason for revert: It breaks a test while rolling into Chromium,
> see https://webrtc-review.googlesource.com/c/src/+/261780/21#message-4a96e33bfb475f19a618be82bbe72951b23085ef for details.
>
> Original change's description:
> > Wait for frames to arrive in WgcCapturer instead of returning nothing.
> >
> > We're seeing a high instance of "first capture failed" in Chromium when
> > using WGC. We can reduce this by waiting for frames to arrive if there
> > are none in the frame pool instead of returning a temporary error.
> >
> > I've set the maximum time to wait for a frame to 50ms. If no frame
> > arrives before 50ms has elapsed, we will return a temporary error.
> > Added a new test, FirstCaptureSucceeds, to verify that this is working
> > as expected.
> >
> > As part of this I updated the name of the `kCreateFreeThreadedFailed`
> > enum value to `kCreateFramePoolFailed`. The value remains the same
> > since they both report failures in frame pool creation.
> >
> > I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
> > store two frames. This should prevent us from having to wait on the
> > event as frequently. This will increase the latency between capture
> > and display, however. High frame rate applications should not be
> > noticeably affected.
> >
> > Additionally, we uncovered a bug in the OS that prevents window capture
> > when there are displays attached, but none of them are active. Added
> > a new check to `IsWgcSupported` to cover this scenario.
> >
> > Finally, some issues with other WGC tests blocked moving the TryBots
> > to a newer version of Windows. This CL fixes those issues and updates
> > the TryBot configuration.
> >
> > bug: chromium:1314868
> > Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
> > Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> > Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> > Commit-Queue: Austin Orion <auorion@microsoft.com>
> > Reviewed-by: Jeremy Leconte <jleconte@google.com>
> > Cr-Commit-Position: refs/heads/main@{#37404}
>
> Change-Id: If237df4826fe20b6fe2ca4b57253623321bf33c5
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267460
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37408}
Change-Id: I6cc2becd9ed363782ab2f326f58d9401bc8fb820
Bug: chromium:1314868
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267902
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#37470}
This reverts commit 93bb3051490253d56dc1cdab4701b91138a151c3.
Reason for revert: It breaks a test while rolling into Chromium,
see https://webrtc-review.googlesource.com/c/src/+/261780/21#message-4a96e33bfb475f19a618be82bbe72951b23085ef for details.
Original change's description:
> Wait for frames to arrive in WgcCapturer instead of returning nothing.
>
> We're seeing a high instance of "first capture failed" in Chromium when
> using WGC. We can reduce this by waiting for frames to arrive if there
> are none in the frame pool instead of returning a temporary error.
>
> I've set the maximum time to wait for a frame to 50ms. If no frame
> arrives before 50ms has elapsed, we will return a temporary error.
> Added a new test, FirstCaptureSucceeds, to verify that this is working
> as expected.
>
> As part of this I updated the name of the `kCreateFreeThreadedFailed`
> enum value to `kCreateFramePoolFailed`. The value remains the same
> since they both report failures in frame pool creation.
>
> I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
> store two frames. This should prevent us from having to wait on the
> event as frequently. This will increase the latency between capture
> and display, however. High frame rate applications should not be
> noticeably affected.
>
> Additionally, we uncovered a bug in the OS that prevents window capture
> when there are displays attached, but none of them are active. Added
> a new check to `IsWgcSupported` to cover this scenario.
>
> Finally, some issues with other WGC tests blocked moving the TryBots
> to a newer version of Windows. This CL fixes those issues and updates
> the TryBot configuration.
>
> bug: chromium:1314868
> Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> Commit-Queue: Austin Orion <auorion@microsoft.com>
> Reviewed-by: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#37404}
Change-Id: If237df4826fe20b6fe2ca4b57253623321bf33c5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267460
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37408}
We're seeing a high instance of "first capture failed" in Chromium when
using WGC. We can reduce this by waiting for frames to arrive if there
are none in the frame pool instead of returning a temporary error.
I've set the maximum time to wait for a frame to 50ms. If no frame
arrives before 50ms has elapsed, we will return a temporary error.
Added a new test, FirstCaptureSucceeds, to verify that this is working
as expected.
As part of this I updated the name of the `kCreateFreeThreadedFailed`
enum value to `kCreateFramePoolFailed`. The value remains the same
since they both report failures in frame pool creation.
I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
store two frames. This should prevent us from having to wait on the
event as frequently. This will increase the latency between capture
and display, however. High frame rate applications should not be
noticeably affected.
Additionally, we uncovered a bug in the OS that prevents window capture
when there are displays attached, but none of them are active. Added
a new check to `IsWgcSupported` to cover this scenario.
Finally, some issues with other WGC tests blocked moving the TryBots
to a newer version of Windows. This CL fixes those issues and updates
the TryBot configuration.
bug: chromium:1314868
Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#37404}
