Previously, we were running the e2e tests from master against
`https://angular.io` (deployed from the stable branch). Often the e2e
tests from master do not apply to the stable branch, since the app has
deviated slightly.
This commit fixes this by stop running the full e2e tests against the
deployed versions, but a smaller set of "smoke tests", which check basic
functionality that is less likely to change between versions.
PR Close#23390
This commit configures a periodic job to be run on CircleCI, performing several
checks against the actual apps deployed to production (https://angular.io) and
staging (https://next.angular.io).
Fixes#21942
PR Close#22483
This should fix the size regression spotted via the previous commit.
-rw-r--r-- 1 iminar eng 72498 Jan 8 00:03 dist/0.86a7a08f7866e6cdc36f.chunk.js
-rw-r--r-- 1 iminar eng 14872 Jan 8 00:03 dist/4.c719ac5645940382cdce.chunk.js
-rw-r--r-- 1 iminar eng 1558 Jan 8 00:03 dist/inline.7722895d8c844f710bcd.bundle.js
-rw-r--r-- 1 iminar eng 453905 Jan 8 00:03 dist/main.faff0e2da95443f759f5.bundle.js
-rw-r--r-- 1 iminar eng 40264 Jan 8 00:03 dist/polyfills.87edf5d695f14a29bf91.bundle.js
-rw-r--r-- 1 iminar eng 54001 Jan 8 00:03 dist/worker-basic.min.js
PR Close#21350
This change introduces a size regression of 9kb for main.js :-(
I filed an issue for this: https://github.com/angular/angular-cli/issues/9108
-rw-r--r-- 1 iminar eng 72546 Jan 5 19:27 dist.cli-1.6.3/0.86a7a08f7866e6cdc36f.chunk.js
-rw-r--r-- 1 iminar eng 14893 Jan 5 19:27 dist.cli-1.6.3/4.c719ac5645940382cdce.chunk.js
-rw-r--r-- 1 iminar eng 1558 Jan 5 19:27 dist.cli-1.6.3/inline.7722895d8c844f710bcd.bundle.js
-rw-r--r-- 1 iminar eng 466484 Jan 5 19:27 dist.cli-1.6.3/main.faff0e2da95443f759f5.bundle.js
-rw-r--r-- 1 iminar eng 40363 Jan 5 19:27 dist.cli-1.6.3/polyfills.87edf5d695f14a29bf91.bundle.js
-rw-r--r-- 1 iminar eng 54001 Jan 5 19:27 dist.cli-1.6.3/worker-basic.min.js
PR Close#21350
This causes a 3.4kb size regressions for polyfills.js. :-(
I filed an issue for this: https://github.com/angular/zone.js/issues/989
-rw-r--r-- 1 iminar eng 73998 Jan 5 17:51 dist/0.5fb611ef423970fd3ba1.chunk.js
-rw-r--r-- 1 iminar eng 14880 Jan 5 17:51 dist/4.c719ac5645940382cdce.chunk.js
-rw-r--r-- 1 iminar eng 1558 Jan 5 17:51 dist/inline.797233300016416206fc.bundle.js
-rw-r--r-- 1 iminar eng 457592 Jan 5 17:51 dist/main.5870135237d5187f1ab6.bundle.js
-rw-r--r-- 1 iminar eng 40684 Jan 5 17:51 dist/polyfills.88f0257676f76560da16.bundle.js
-rw-r--r-- 1 iminar eng 54001 Jan 5 17:51 dist/worker-basic.min.js
PR Close#21349
The scripts were accidentally broken in #20524. More specifically, when a limit
was exceeded the script would break while trying to log an error message due to
a missing `commit` variable.
This commit fixes it and also does some minor clean-up (improve docs, use more
descriptive variable names, remove dead code, etc).
PR Close#20683
-rw-r--r-- 1 iminar eng 14880 Oct 30 11:29 dist/0.b19e913fbdd6507d346b.chunk.js
-rw-r--r-- 1 iminar eng 1533 Oct 30 11:29 dist/inline.25600c3b48de18b97581.bundle.js
-rw-r--r-- 1 iminar eng 486476 Oct 30 11:29 dist/main.d1292a34401056535884.bundle.js
-rw-r--r-- 1 iminar eng 37070 Oct 30 11:29 dist/polyfills.0dfca732c5a075c110d0.bundle.js
PR Close#19702
There are now 3 modes for deployment: next, stable, archive.
We compute which mode (and other deployment properties)
from the `TRAVIS_BRANCH` and the `STABLE_BRANCH`.
If the TRAVIS_BRANCH is master we deploy as "next".
If the `TRAVIS_BRANCH` matches the `STABLE_BRANCH` we deploy as "stable".
Otherwise if the branch has a major version lower than the stable version
and its minor version is highest of similar branches we deploy as "archive".
For "archive" deployments we compute the firebase project and deployment
url based on the major version of the `TRAVIS_BRANCH`.
As well as choosing where to deploy the build, we also use this
to select the environment file for the AIO Angular app.
This will enable the app to change its rendering and behaviour
based on its mode.
See #18287Closes#18297
There are now 3 modes for deployment: next, stable, archive.
We compute which mode (and other deployment properties)
from the `TRAVIS_BRANCH` and the `STABLE_BRANCH`.
If the TRAVIS_BRANCH is master we deploy as "next".
Otherwise if the branch is the highest of its minor versions
we deploy as "stable" if the `TRAVIS_BRANCH` matches the `STABLE_BRANCH` or
else "archive".
For "archive" deployments we compute the firebase project and deployment
url based on the major version of the `TRAVIS_BRANCH`.
As well as choosing where to deploy the build, we also use this
to select the environment file for the AIO Angular app.
This will enable the app to change its rendering and behaviour
based on its mode.
See #18287
Firebase does not allow `.` in the path, so when trying to upload payload size
data for branches like `4.2.x`, the following error is thrown:
```
HTTP Error: 400, Invalid path: Invalid token in path
```
This commit fixes it by replacing `.` with `_` in branch names.
There have been some issues lately with Travis jobs failing due to
`print-log.sh`. This is likely due to trying to print the Lighthouse PWA report,
which is too large.
This commit stops printing that report (since it was rarely used and is pretty
easy to acquire when needed) and restores the `print-logs.sh` script (that was
temporarily removed with dfcca66fd).
Previously, there was an issue with testing the PWA score on staging and failing
the build was temporarily disabled. It works now, so we need to enable failing
the build is the score drops below some threshold.
You can now specify what environment you are building
by add it to the `yarn build` command. For example:
```
yarn build -- --env=stage
```
Moreover the `deploy-to-firebase.sh` script will automatically apply the
appropriate environment.
The current stable branch is determined based on the current version mapped to
the npm `latest` tag (by replacing the patch version number with 'x' - e.g.
`1.2.3` --> `1.2.x`).
PRs against the stable branch will be deployed to the preview server (as long as
the rest of the requirements are met). Commits on the stable branch itself will
be deployed to production.
Fixes#16908
Lighthouse v1.6.5 treats localhost/1.2.7.0.0.1 as secure domains (i.e. as if they where HTTPS), so we need to stop handling the is-on-https audit specially.
In some cases (unclear when), traceviewer-js, used by Lighthouse under the hood,
assumes `atob`/`btoa` are defined in the global scope. This is true for browser
environments, but not on node.
As a result, some aggregations that required access to model-tracing failed to
produce results, dropping the overall PWA score.
This affected #16665 (e.g. commit 0de6eec7a).
(Coincidentally), this wasn't an issue before fdfeaaf1f, because
pre-verification was run after `test.sh`, during which `aio-builds-setup` was
built.
Now that `deploy-staging.sh` is being run before `test.sh`, we need to build
the `aio-builds-setup` scripts first.
Previously, `aio/aio-builds-setup/scripts/travis-preverify-pr.sh` was supposed
to exit with 1 if a PR did not meet the preconditions and 2 if an error occurred
during pre-verification.
It relied on the exit codes of the node script that did the actual work, but
didn't account for errors that would be thrown in the `sh` script itself (e.g.
if the node script was not available). This caused such errors to appear as
non-verified PRs, instead of real errors that should fail the build.
This commit swaps the exit codes, so that now a 2 means non-verified PR and 1
designates an error.
Previously, no previews would be deployed for PRs that didn't touch files inside
`aio/`. Now, previews will be deployed for PRs that touch non-spec files inside
either `aio/` or `packages/` (as long as other preconditions are met).
Partially addresses #16526.
Currently, running `yarn test-pwa-score` right after deploying to staging fails
with the error:
```
{ Error: Unable to load the page: timeout reached ... code: 'PAGE_LOAD_ERROR' }
```
As a temporary fix, this commit prevents the build from failing because of PWA
score errors (until we identify the cause and fix it).
Previously, when trying to upload the build artifacts for a PR/SHA that was
already successfully deployed (e.g. when re-running a Travis job), the preview
server would return a 403 and the build would fail.
Since we have other mechanisms to verify that the PR author is trusted and the
artifacts do indeed come from the specified PR and since the new artifacts
should be the same with the already deployed ones (same SHA), there is no reason
to fail the build. The preview server will reject the request with a special
HTTP status code (409 - Conflict), which the `deploy-preview` script will
recognize and exit with 0.
This reverts commit d0bc83ca27.
Protractor-based prerendering is flakey on Travis and takes several minutes to
complete, slowing down the build. Prerendering has a lower impact now that we
use a ServiceWorker. We will revisit in the future (probably using a
`PlatformServer`-based approach).
PR Close#15346
Gaining access to another PR's JWT, would allow faking that PR's author wrt to
GitHub team membership verification for as long as the JWT is valid (currently
90 mins).
Igor Minar
George Kalpakas
JiaLi.Passion
Andrew Seguin
Miško Hevery
Jesus Rodriguez
Pete Bacon Darwin
Yuan Gao
Filipe Silva
Kara Erickson
Alex Rickabaugh
Igor Minar