This script supports two commands:
deflake:
This command will go through all status file entries and check if the actual
testoutcomes we've observed on our buildbots match the status file entries.
If we have tests marked as flaky which are in fact not flaky, it will write
a *.status.deflaked file which contains the fixes to the status file.
fix:
This command will go through all status files and ensures that all the
status file lines correspond to existing tests.
If we have lines that refer to non-existent tests, it will write a
*.status.fixed file which contains the fixes to the status file.
R=whesse@google.com
Review URL: https://codereview.chromium.org//143453012
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32694 260f80e4-7a28-3924-810f-c04153c831b5
"package/" under the web/ directory. Resolution under 'lib' is the same, but it and gives better suggestions if the path looks wrong. This summarizes what changed:
- source file: lib/b.html
import to "packages/c/d.html" was error, now is error + suggestion
import to "../packages/c/d.html" was error, now is error + suggestion
import to "../../packages/c/d.html" was resolved, now is resolved too
- source file: lib/a/b.html
import to "packages/c/d.html" was error, now is error + suggestion
import to "../packages/c/d.html" was error, now is error + suggestion
import to "../../packages/c/d.html" was error, now is error + suggestion
import to "../../../packages/c/d.html" was resolved, now is resolved too
- source file: web/b.html
import to "packages/c/d.html" was and continues to be resolved
import to "../packages/c/d.html" was error, now is resolved
- source file: web/a/b.html
import to "packages/c/d.html" was error, now is resolved
import to "../packages/c/d.html" was and continues to be resolved
import to "../../packages/c/d.html" was and continues to be resolved
Note: polymer-build and development mode are slightly different: polymer-build
detects and issues an error for bad paths inside lib/. These are not detected by
our package-resolution in loader.dart, but as long as users are not creating
symlinks by hand, Dartium should detect if the paths are wrong.
When we switch to start using pub-serve by default, we should be able to go back
to the web-ui style of using "package:" urls directly in HTML.
R=jmesserly@google.com, kustermann@google.com
Review URL: https://codereview.chromium.org//148913003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32170 260f80e4-7a28-3924-810f-c04153c831b5
This will be used on the bots to be able to archive dumps from unexpectec crashes.
The tools/archive_crash.py tool will be used to actually archive the dumps to gcs and delete the local copies. The reason for the split is to enable developers to actually utilize this locally as well (run tools/test.py in a loop but don't archive the expected crashes). Additionally, this puts the bot specific code in the small python script.
R=whesse@google.com
Review URL: https://codereview.chromium.org//145273024
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32111 260f80e4-7a28-3924-810f-c04153c831b5
For all tests that depend on other packages (e.g. samples) we can
- use packages from pub.dartlang.org
- use packages from pub.dartlang.org with overrides for the packages we have
in the dart repository.
This CL does NOT include test-specific package-roots for dartium. Dartium will request a URL containing
"packages" when it encounters a package import. Our HTTP server will then serve from buildDir/packages.
This needs to change when we have test specific VMOptions for dartium.
For normal tests (without a pubspec.yaml on the path to dart/, we still use buildDir/packages).
R=ricow@google.com, whesse@google.com
Review URL: https://codereview.chromium.org//126173002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@31691 260f80e4-7a28-3924-810f-c04153c831b5
This CL adds
- support for fetching dependencies via 'pub get' of samples/packages
- support for building applications/samples via 'pub build' (or a custom
build.dart file)
- pkg/pkgbuild.status: Status files for all package checkouts/builds
- the '--use-public-packages' option to test.dart
- the CleanDirectoryCopyCommand, PubCommand, ModifyPubspecYamlCommand commands
The test suite can be executed with:
$ ./tools/test.py -mrelease --use-sdk pkgbuild
$ ./tools/test.py -mrelease --use-sdk --use-public-packages pkgbuild
R=ricow@google.com
Review URL: https://codereview.chromium.org//122443003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@31535 260f80e4-7a28-3924-810f-c04153c831b5
I am aware that we should not clutter up the message that we show to developers, but I think it is important to validate that we actually send the onDone message to the driver page.
We should also put in functionality for tracking network errors in the browser_controller generated js (+potentially retrying the send of the message)
R=kustermann@google.com
Review URL: https://codereview.chromium.org//96503002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30771 260f80e4-7a28-3924-810f-c04153c831b5
Currently test.py will look for FAIL/PASS messages in the DOM to determine if a
test has failed or not. test_controller.js will add these PASS/FAIL messages to
the DOM (in addition to other messages).
This approach has several issues:
- The test itself could create nodes in the DOM containing FAIL/PASS. This means
that the outcome of a test cannot be reliably determined.
- The test ifself can remove nodes from the DOM (e.g. setting
document.body.innerHTML). This could result in a situation where the
stacktraces/... test_controller.js prints to the DOM are lost.
- It is unclear which parts of the DOM we see in test failure messages
(reported by test.py) come from the test itself and which parts come from
test_controller.js.
This CL tries to fix this by recording all events that happend with global
variables in test_controller.js and send back a JSON string with information
about
- debug messages
- posted messages
- print() calls of the test
- DOM
- errors (from window.onerror, script.onerror ...)
Furthermore this CL fixes unittest to report
unittest-suite-success/unittest-suite-fail instead of unittest-suite-done (which
is broken).
R=ricow@google.com
Review URL: https://codereview.chromium.org//36913002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30407 260f80e4-7a28-3924-810f-c04153c831b5
sigurdm@google.com