We've recently marked the ngtsc test as flaky for the Windows
job. We should not attempt running tests 3 times locally. This
negatively impacts the debugging/developer workflow.
Instead, flaky test attempts can still be made on CI. Using the
default attempt count of 3.
PR Close#50852
Enables colors for Bazel in CircleCI. Bazel does not seem to
detect color support properly, but CircleCI does support such.
Colors make debugging a little easier with larger Bazel logs.
PR Close#50720
Bazel otherwise may almost look as being stuck when it performs
many slow e2e tests. We should show what is running, even it results
in a little more output in the logs.
PR Close#48316
* Added a /tools/saucelabs/sauce-service.sh script that manages the sauce-connect as a service which is used by the karma-saucelabs.js wrapper to start the service.
* Added /tools/saucelabs/README.md that covers the details of SauceLabs karma testing with Bazel.
PR Close#34769
Currently we only run Saucelabs on PRs using the legacy View Engine
build. Switching that build to Ivy is not trivial and there are various
options:
1. Updating the R3 switches to use POST_R3 by default. At first glance,
this doesn't look easy because the current ngtsc switch logic seems to
be unidirectional (only PRE_R3 to POST_R3).
2. Updating the legacy setup to run with Ivy. This sounds like the easiest
solution at first.. but it turns out to be way more complicated. Packages
would need to be built with ngtsc using legacy tools (i.e. first building
the compiler-cli; and then building packages) and View Engine only tests
would need to be determined and filtered out. Basically it will result in
re-auditing all test targets. This is contradictory to the fact that we have
this information in Bazel already.
3. Creating a new job that runs tests on Saucelabs with Bazel. We specify
fine-grained test targets that should run. This would be a good start
(e.g. acceptance tests) and also would mean that we do not continue maintaining
the legacy setup..
This commit implements the third option as it allows us to move forward
with the general Bazel migration. We don't want to spend too much time
on our legacy setup since it will be removed anyway in the future.
PR Close#34277
Removes the selection strategies for `AngularTemplateCompile` and `TypeScriptCompile` causing
them to use the automatic selection strategies instead.
PR Close#32678
Paul Gschwendtner