The goal of https://github.com/angular/components/commit/2ce5ffd56b70c3791331ceedeadc1f1f6daf3924 was to avoid the
use of Bazel through the `node_modules` because it adds unnecessary code overhead, slows down CI and means that
some tools need to be installed multiple times (such as `yarn`). Unfortunately when building a release with Bazel
right now, the bazel workspace status script depends on the global `node` binary. This means that we need
to bring in Node when running with the `--config=release` flag.. Since that causes inconsistent behavior
and just complicates the setup, we are using Bazel through Yarn for now. Similar to how we did it for
`angular/angular` with https://github.com/angular/angular/commit/8fc4ae51fb66d14f6dc82712a536c3842205fc6d.
We currently wait for browser tunnels of Saucelabs and Browserstack
to terminate by repeatedly checking with `ps -p`. This is not reliable and
can break if the host system is not removing forcibly killed child processes
from the process table. This is valid since the tunnels are launched as child
processes and we ideally wait for those to terminate using the `wait` command.
In order to be able to take advantage of Google's official
bazel docker images, we no longer can use a NodeJS script
for setting up the snapshot builds because NodeJS is not
installed in the image. Rather we need to convert the script
to a python script in order to be able to perform the package.json
modification.
Since this script is not intended to be executed locally, we
are free to use Python for this.
We no longer use Bazel from the `ngcontainer` image as it is
no longer maintained and we need to use the latest version of
Bazel in CircleCI. It's not ideal to use Bazel through Yarn since
binaries like that should be actually part of the docker image, but
for now we need to do this for jobs that use NodeJS & Bazel at the same time.
This is similar to what `angulart/angular` does.
Introduces two new CI jobs that run tests with Ivy.
Pull requests will now run tests against a pinned
Angular/Ivy version. Additionally there is a cronjob
that runs the component tests with Ivy every hour
against Ivy from `angular/angular#master`. This allows
us to detect regressions very quickly.
This should capture things that reference the GitHub repository.
There are many other places we use "material2" that we can clean up in
subsequent changes.
We currently face a lot of flakiness with our Saucelabs job. These randomly exceed the 2min establish timeout because something throws
off `sauce-connect` in a long-lasting loop where it tries to connect to some of their Saucelabs servers. The initial assumption from the Saucelabs
team was that we might have some invalid firewall rules, but this does not answer why this happens _randomly_, so the latest update from the support
is that there have been some changes in the latest version of `sauce-connect` version that cause this flakiness.
* Similarly to `angular/angular`, we should publish our artifacts using `git push --force`. This avoids the race condition where another CI job pushes to the builds repository before we try to push with our outdated `HEAD`.
* build: increase saucelabs connect timeout
At some point we went down from a 2min wait timeout to 30seconds because we re-ran the startup script if something failed. Since re-running didn't really help and we removed it, we should move the timeout back to a longer period.
e.g. see: https://circleci.com/gh/angular/material2/25254 where it successfully acquired a tunnel, but just didn't have enough time to actually establish it.
* Switch to rewritten saucelabs version
* Update to latest saucelabs launcher version
Apparently the script that also ran on TravisCI does not work on MacOS, nor on CircleCI because it's not guaranteed that the default awk supports storing match() results in an array that can print individual match groups.
* Due to the fact that the `CIRCLE_WORKFLOW_ID` does not actually return the name of the workflow, but a unique id that is generated dynamically, the cronjob does not run against the Angular github builds.
* Sets up a cronjob workflow that runs the local browser tests against the Angular Github snapshot builds at midnight everyday.
* No longer saves cache multiple times. This can cause unexpected behavior.
* Sorts jobs in `config.yml` to group all `tests_XX` jobs.
Closes#12516.
* Currently it can happen that our tunnel identifier conflicts with other tunnel identifiers from other Angular projects. A few PRs reported that their tunnel couldn't be re-opened because it was already used and closed successfully.
* Since we going to move from Travis to CircleCI we don't want to use the dashboard anymore. Since nobody has been
looking at the dashboard frequently, it just makes things more complicated and additionally we will be using
the Github robot in order to keep track of size changes.
* Updates to the latest `dgeni-packages` version that includes: https://github.com/angular/dgeni-packages/commit/5d90fd9f31541f380a62a52fd31493b232b9585c. This allows us to remove a workaround.
* Removes the closure testing stuff that hasn't been used for months. In case we want to reintroduce testing w/ Google Closure, we should consider using Bazel or something (AFAIK there are Bazel rules for closure)
* Due to the fact that we modify the `package.json` in cronjobs without updating the actual lock-file, the `--frozen-lockfile` installation fails. In order to fix this, we should just re-install the dependencies after the general `yarn` installation.
* Since we lock our dependencies in the `yarn.lock` file, we need to enforce that the lock file is in sync with the `package.json` file (similar as in angular/angular)
* Since we cache the dependenices & the yarn cache within Travis, it can happen that the node modules are stale (there is no checksum mechanism in Travis). In that case we need to purge the node modules and re-install.
* No longer runs e2e tests inside of Saucelabs because Chrome is also installed on Travis CI and we should keep Saucelabs available for other browsers that don't run inside of Dockers or Travis.
Currently the docs-content output will be overwritten each time a Travis job runs in another branch (e.g. `master`, `6.4.x`, `6.x`). This is because the given branches cannot be created in the `material2-docs-content´ repository.
This is not good because if we want to release a new patch version, we have no way to properly pull the docs-content data that matches the given new version. Meaning that the docs-content and the `@angular/material-examples` package might be already updated for the next `major` version and we run into runtime exceptions due to the breaking changes.
* Updates the Saucelabs Connect Tunnel to the most recent version that seems to include a major bug fix that should improve tunnel stability
* Changes the CircleCI resource class to the `xlarge` (similar as in angular/angular). This should speed up the Bazel builds due to more CPU threads and more RAM.
* No longer just runs the tests against the first browser of a test platform (travis, saucelabs, browserstack)
* Stability is more valuable than speed (runs sequentially on CI now)
* Update Saucelabs Connect
* Remove unused spec reporter
* Update from Edge 14 to Edge 17
* Fix pixel deviations in Edge 17
No longer runs the build artifacts, docs-content, dashboard, screenshot deployment tasks on Pull Requests. This means that there aren't any noop jobs running anymore
Joey Perrott