Skip to content

Conversation

@aam
Copy link
Member

@aam aam commented Feb 15, 2018

cc: @a-siva

@a-siva
Copy link
Contributor

a-siva commented Feb 16, 2018

The changes look good but I am not sure why you are getting test errors in all the shards. Maybe you should sync up and try the tests again to see what state they end up in.

.travis.yml Outdated
- os: osx
env: SHARD=docs
- os: osx
env: SHARD=tests_dart2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this excludes it from osx. i think we want it enabled for osx, no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was not sure we want to run them on osx, but enabled now.

await _pubRunTest(path.join(flutterRoot, 'packages', 'flutter_tools'));
await _pubRunTest(path.join(flutterRoot, 'dev', 'bots'));

await _runAllDartTests(path.join(flutterRoot, 'dev', 'devicelab'));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we run dart tests with preview2 too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that should be possible.

await _runFlutterTest(path.join(flutterRoot, 'packages', 'flutter_driver'), options: options);
await _runFlutterTest(path.join(flutterRoot, 'packages', 'flutter_test'), options: options);
await _pubRunTest(path.join(flutterRoot, 'packages', 'flutter_tools'));
await _pubRunTest(path.join(flutterRoot, 'dev', 'bots'));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about these?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how pub run can run in dart2 mode.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to file an issue against pub for this.
Currently it has the following options for pub run
Usage: pub run [args...]
-h, --help Print this usage information.
-c, --[no-]checked Enable runtime type checks and assertions.
--mode Mode to run transformers in.
(defaults to "release" for dependencies, "debug" for entrypoint)

it needs another option here '--preview-dart-2' to be consistent that would run in dart2 mode.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@a-siva
Copy link
Contributor

a-siva commented Feb 17, 2018

Maybe we should move running under dart2 mode to the Allowed Failure section so that we can land this PR and then fix up the tests.

@aam
Copy link
Member Author

aam commented Feb 17, 2018

Maybe we should move running under dart2 mode to the Allowed Failure section so that we can land this PR and then fix up the tests.

I would have been happy to do that, but I'm seeing some weird timeout issues with running dart2 tests all at once. It looks like machine performance tanks when you run ~30 frontend tests in parallel(15 tests work).

@aam
Copy link
Member Author

aam commented Feb 17, 2018

Maybe we should move running under dart2 mode to the Allowed Failure section so that we can land this PR and then fix up the tests.

I would have been happy to do that, but I'm seeing some weird timeout issues with running dart2 tests all at once. It looks like machine performance tanks when you run ~30 frontend tests in parallel(15 tests work

Limiting concurrency to 4 seems to work fine.

@mraleph
Copy link
Member

mraleph commented Feb 17, 2018

I think we need to investigate reusing a single frontend_server instance for running multiple tests. Spawning a new one per test is likely way too much overhead.

@mraleph
Copy link
Member

mraleph commented Feb 17, 2018

FYI: flutter_driver test failures should be fixed by dart-lang/sdk@eb997b2, I also filed dart-lang/sdk#32185 and dart-lang/sdk#32183 for compilation errors in file and vmservice_client packages.

aam added 4 commits February 22, 2018 16:26
Actually use single compiler to incrementally recompile all tests executed by 'flutter test'.
bool isEmpty = compilationQueue.isEmpty;
compilationQueue.add(request);
// Only trigger processing if queue was empty - i.e. no other requests
// we being processed. This effectively enforces "one compilation request at a time".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no other requests are currently being processed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Done.

compiler.accept();
compiler.reset();
request.result.complete(outputPath);
// Only remove now when we finished processing the element
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in what circumstance would we try recompiling the same test again ? I am wondering why is is necessary to remove the request only after we are done with the compilation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not that we are going to recompile the same test again. We only remove the test from the queue after we are done compiling because that way we know that no other compilation request can start before we exit(no await statements from this point on).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok got it.

@a-siva
Copy link
Contributor

a-siva commented Mar 1, 2018

What is the final outcome of this, do we run the Travis tests using the batch compiler? I thought this would cause timeouts as we would exceed the Travis time budgets.

@aam
Copy link
Member Author

aam commented Mar 1, 2018

What is the final outcome of this, do we run the Travis tests using the batch compiler? I thought this would cause timeouts as we would exceed the Travis time budgets.

Correct, this is now blocked on incremental compiler issue revealed in #14931.

@aam
Copy link
Member Author

aam commented Mar 1, 2018

Blocked on dart-lang/sdk#32368

@aam
Copy link
Member Author

aam commented Mar 1, 2018

With dart-lang/sdk#32368 fixed, this PR that shares frontend server between tests travis build in preview-dart-2 takes 26m47s, "only" 20s more than non-preview-dart-2 test, so is ready to be submitted I believe.

@aam aam merged commit d379762 into flutter:master Mar 1, 2018
@aam aam deleted the run-test-dart2 branch March 1, 2018 17:04
@mraleph
Copy link
Member

mraleph commented Mar 2, 2018

It looks more like 3 minutes slower on Mac, but 8 minutes slower on Linux if I am not misreading the output.

build__21078_-_flutter_flutter_-_travis_ci

I think this warrants investigation, to see if we can do something about it /cc @jensjoha @kmillikin

@aam
Copy link
Member Author

aam commented Mar 2, 2018

as @Hixie pointed out comparing numbers from Build Jobs dashboard does not paint full picture as preview-dart-2 tests don't run all the way to the completion.
Better comparison at this point would be to look at execution of flutter test in packages/flutter which completes successfully in both configurations:

  • 06:13 +2327 ~16: All tests passed! without preview-dart-2 vs
  • 18:28 +2327 ~16: All tests passed! with preview-dart-2

@tvolkert
Copy link
Contributor

tvolkert commented Mar 7, 2018

Looks like this broke internal Google tests - /cc @keertip

@tvolkert
Copy link
Contributor

tvolkert commented Mar 7, 2018

And looks like @jason-simmons already has a fix internally

@jensjoha
Copy link
Contributor

jensjoha commented Mar 8, 2018

For now I have a few comments:

  • Running flutter test --preview-dart-2 in packages/flutter doesn't work for me at all. The VM crashes because of a deleted file after which all tests time out (after 12 minutes!). I have a fix for that though (fix in dart sdk/pkg/vm; still not uploaded).
  • When running flutter test my computer uses 100% CPU on all (12) cores, when running flutter test --preview-dart-2 it uses 100% CPU on 1 core and "a little bit" on the other ones.
  • The tests basically does this: recompile, accept, reset, where reset throws away the compiler inside the frontend_server and creates a new one. That doesn't seem ideal.

After fixing whats talked about in bullet-point #1 above I get

  • 01:10 +2334 ~16: All tests passed! (flutter test --local-engine=host_debug)
  • 08:34 +2333 ~16 -1: Some tests failed. (flutter test --preview-dart-2 --local-engine=host_debug)

DaveShuckerow pushed a commit to DaveShuckerow/flutter that referenced this pull request May 14, 2018
…lutter#14728)

* Run flutter tests in preview-dart-2 mode on travis flutter builds.

* Run dart2 tests on osx. Run dart tests in dart2.

* Fix name camelCase

* Default options to empty array, rather than null

* Troubleshoot failures

* More logging

* Troubleshoot: run single test

* Troubleshoot: run 15 tests

* Troubleshoot: run 15 tests with fix

* Try limit concurrency to 1

* Limit concurrency for preview-dart-2 tests to 4

* Move dart2 tests to allow_failures section

* Reinstate tests_dart_2 shard

* Raise concurrency to 8

* Reuse compiler across multiple test runs

* Allow to switch entry points when recompiling.

Actually use single compiler to incrementally recompile all tests executed by 'flutter test'.

* Remove leftover commented code

* Fix comment

* Lints
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants