build: add blocklist for material unit tests (#32239)

Initially the blocklist has been removed because there were
no remaining disabled tests that failed. Also the blocklist
logic didn't work anymore because the `material-unit-tests` CI
job now runs against `angular/components#master` with Bazel.

388578fec9 tried to revert the removal
of the blocklist in favor of a new upcoming breaking change with
HammerJS, but the revert doesn't help since the blocklist still
doesn't work with Bazel.

In order to make the blocklist work with the unit tests running
with Bazel, a PR has been submitted on the components repository.
See: https://github.com/angular/components/pull/16833.

This commit updates the blocklist logic on the framework side to
work with the new logic on the components repo side.

PR Close #32239
This commit is contained in:
Paul Gschwendtner 2019-08-21 15:35:44 +02:00 committed by Andrew Kushnir
parent 64770571b2
commit 62f4140634
4 changed files with 60 additions and 43 deletions

View File

@ -21,9 +21,9 @@ cd ${MATERIAL_REPO_TMP_DIR}
# Note that it's not necessary to perform a yarn install, as Bazel performs its own yarn install. # Note that it's not necessary to perform a yarn install, as Bazel performs its own yarn install.
node ${angular_dir}/scripts/ci/update-deps-to-dist-packages.js ${MATERIAL_REPO_TMP_DIR}/package.json ${angular_dir}/dist/packages-dist-ivy-aot/ node ${angular_dir}/scripts/ci/update-deps-to-dist-packages.js ${MATERIAL_REPO_TMP_DIR}/package.json ${angular_dir}/dist/packages-dist-ivy-aot/
# Append the test blocklist into angular/material2's karma-test-shim.js. # Copy the test blocklist into the "angular/components" repository. The components
# This filters out known-failing tests because the goal is to prevent regressions. # repository automatically picks up the blocklist and disables the specified tests.
cat ${angular_dir}/tools/material-ci/angular_material_test_blocklist.js >> ./test/karma-test-shim.js cp ${angular_dir}/tools/material-ci/test-blocklist.ts ${MATERIAL_REPO_TMP_DIR}/test/
# Create a symlink for the Bazel binary installed through NPM, as running through Yarn introduces OOM errors. # Create a symlink for the Bazel binary installed through NPM, as running through Yarn introduces OOM errors.
./scripts/circleci/setup_bazel_binary.sh ./scripts/circleci/setup_bazel_binary.sh

View File

@ -1,20 +0,0 @@
/**
* @license
* Copyright Google Inc. All Rights Reserved.
*
* Use of this source code is governed by an MIT-style license that can be
* found in the LICENSE file at https://angular.io/license
*/
/**
* Blocklist of unit tests from angular/material2 with ivy that are skipped when running on
* angular/angular. As bugs are resolved, items should be removed from this blocklist.
*
* The `notes` section should be used to keep track of specific issues associated with the failures.
*/
// clang-format off
// tslint:disable
window.testBlocklist = {};
// clang-format on

View File

@ -1,24 +1,32 @@
### Unit tests for Angular CDK/Material ### Unit tests for Angular CDK/Material
The unit tests from angular/material2 run on CircleCI under the `material-unit-tests` job.
Known failing tests are skipped based on the blocklist in Currently, all changes to Ivy are validated against the test suite of the
`tools/material-ci/angular_material_test_blocklist.js`. Whenever the root cause of a known failure `angular/components` repository. Known failing tests are skipped based on
is identified, the `notes` field for the corresponding tests should be updated. Whenever a failure the blocklist in `tools/material-ci/test-blocklist.ts`.
is resolved, the corresponding tests should be removed from the blocklist.
Whenever the root cause of a known failure is identified, the `notes` field
for the corresponding tests should be updated. Whenever a failure is resolved,
the corresponding tests should be removed from the blocklist.
### Debugging ### Debugging
To debug a failure, you need to work against the angular/material2 repo:
1. Clone `angular/material2`
2. Checkout the `ivy-2019` branch
3. Run `yarn`
4. Run `scripts/ivy/install-angular.sh path/to/local/angular/repo`
5. Run `gulp test`
### Regenerating the blocklist Information on debugging can be found [here](../../docs/DEBUG_MATERIAL_IVY.md).
If a problem has been fixed, you can regenerate the blocklist by:
1. Clone `angular/material2` ### Excluding new tests
2. Checkout the `ivy-2019` branch
3. Run `yarn` In case there are any tests in the components test suite that fail due to
4. Run `scripts/ivy/install-angular.sh path/to/local/angular/repo` recent changes in the framework and you want to exclude the tests temporarily,
5. Run `gulp test`. Let it finish. It will take a few minutes. a new entry can be added to the `test-blocklist.ts` file.
6. Run `scripts/ivy/generate-blocklist.js path/to/local/angular/repo`
7. Copy the new blocklist from `dist/angular_material_test_blocklist.js` Each property in the blocklist object corresponds to a test in the components
repository. The name of the property **must** match the exact test name. Additionally
it's **recommended** that every entry has a field with a note on why the test is disabled.
```ts
export const testBlocklist: any = {
'MatSlider should be able to drag thumb': {
error: 'Cannot register event "dragstart".',
notes: 'Breaking change where HammerJS module needs to be imported.'
}
}
```

View File

@ -0,0 +1,29 @@
/**
* @license
* Copyright Google Inc. All Rights Reserved.
*
* Use of this source code is governed by an MIT-style license that can be
* found in the LICENSE file at https://angular.io/license
*/
// clang-format off
// tslint:disable
interface BlocklistEntry {
/** Description on why the given test is disabled. */
notes: string;
/** Optional error that has been thrown in the test. */
error?: string;
}
/**
* List of tests that should not run in the Angular component test suites. This should
* be empty in the components repository, but the file will be overwritten if the framework
* repository runs the Angular component test suites against the latest snapshots. This is
* helpful because sometimes breaking changes that break individual tests land in the framework
* repository. It should be possible to disable these tests until the component repository
* migrated the broken tests.
*/
export const testBlocklist: {[testName: string]: BlocklistEntry} = {};
// clang-format on