-
Notifications
You must be signed in to change notification settings - Fork 26.2k
aio: add monitoring and fix a couple of issues #22483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
You can preview 676a999 at https://pr22483-676a999.ngbuilds.io/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor nits that you can choose to ignore but otherwise looks good.
I like what you did with redirect and sitemap testing !
.debounceTime(this.checkInterval) | ||
.startWith(null) | ||
constructor(appRef: ApplicationRef, private logger: Logger, private sw: NgServiceWorker) { | ||
const appIsStable$ = appRef.isStable.filter(v => v).first(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this can be simplified to:
appRef.isStable.first(v => v);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had no idea about this 💯
@@ -60,7 +62,7 @@ export class SwUpdatesService implements OnDestroy { | |||
this.sw.checkForUpdate() | |||
// Temp workaround for https://github.com/angular/mobile-toolkit/pull/137. | |||
// TODO (gkalpak): Remove once #137 is fixed. | |||
.concat(Observable.of(false)).take(1) | |||
.concat(of(false)).first() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand it we want to emit a false if the stream closes without emitting anything, right?
If so, can this be simplified to the following?
.defaultIfEmpty(false)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't know about this one either. Nice!
(I see someone knows their RxJS 😃)
aio/src/main.ts
Outdated
@@ -11,7 +13,7 @@ if (environment.production) { | |||
platformBrowserDynamic().bootstrapModule(AppModule).then(ref => { | |||
if (environment.production && 'serviceWorker' in (navigator as any)) { | |||
const appRef: ApplicationRef = ref.injector.get(ApplicationRef); | |||
appRef.isStable.first().subscribe(() => { | |||
appRef.isStable.filter(v => v).first().subscribe(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can be simplified to:
appRef.isStable.first(v => v).subscribe(() => {
@@ -1,8 +1,8 @@ | |||
import { getRedirector, loadLegacyUrls, loadRedirects, loadSitemapUrls } from './helpers'; | |||
import { getRedirector, loadLegacyUrls, loadRedirects, loadLocalSitemapUrls } from '../shared/helpers'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT loadLocalSitemapUrls
does not exist...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see it was added in a later commit :-O
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops 😁
@@ -180,3 +182,8 @@ | |||
/news.html https://blog.angular.io/ | |||
/testing /guide/testing | |||
/testing/first-app-tests.html /guide/testing | |||
|
|||
# These URLs are deliberately put at the end in order to ensure that the ServiceWorker will have | |||
# been installed. This allows verifying that the SW will indeed let them pass through to the server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you relying upon the SW loading during processing of these tests? Why else would it matter that they are at the end of the file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I rely on the SW being loaded.
Essentially, if you put these URLs at the top of the file (where they belong alphabetically 😁), they are navigatd to before the SW has been installed. As a result, they pass through to the server, where they are redirected correctly.
Once the SW has been activated and handles navigation, these URLs will only pass through to the server if they are not matched by the routing RegExp in ngsw-manifest.json
.
In other words:
Having the URLs at the top would allow the tests to pass even with the current (broken) RegExp on master.
Having the URLs at the end, makes the tests fail on master (and pass with the fix in this PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What? Surely not?
Is there not some other mechanism to ensure that the SW has been activated before running these tests?
Perhaps a dummy request in the protractor spec or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just realized my comment might be confusing, because I am referring to the e2e tests added in the next commit 😁
The jasmine tests (run with yarn deployment-config-test
) will correctly fail/pass regardless where you put the URLs 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand but I still think it is rather flakey to rely upon the order of the test data in this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know 😞
(TBH, I don't think it matters, because we already assert that these URLs are handled correctly by the SW in depoyment-config-test
, but I will look into it.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't find a reliable way to ensure that the ServiceWorker has been activated, but I also think that we mainly want to check the Firebase server (since we are pretty confident about the SW routing RegExp based on the tests in deployment-config-test
).
So, I changed the code to instead unregister the SW before each test 😁
"build-ie-polyfills": "node node_modules/webpack/bin/webpack.js -p src/ie-polyfills.js src/generated/ie-polyfills.min.js", | ||
"update-webdriver": "webdriver-manager update --standalone false --gecko false $CHROMEDRIVER_VERSION_ARG", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT renaming ~update-webdriver
to update-webdriver
is the only real change in this file, right? Or am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty much 😇
@@ -34,6 +28,27 @@ export function loadLegacyUrls() { | |||
.map(line => line.split('\t')); // Split lines into URL pairs. | |||
} | |||
|
|||
export function loadLocalSitemapUrls() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahah! I see that the non-existent loadLocalSitemapUrls
was a rebase mismatch.
676a999
to
7873194
Compare
You can preview 7873194 at https://pr22483-7873194.ngbuilds.io/. |
7873194
to
9148010
Compare
You can preview 9148010 at https://pr22483-9148010.ngbuilds.io/. |
c3a91a8
to
52ceab0
Compare
@petebacondarwin, I added a bunch of fixup commits. (I didn't touch the non-fixup commits other than rebasing on master.) PTAL |
You can preview 52ceab0 at https://pr22483-52ceab0.ngbuilds.io/. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks great otherwise. I just wonder if testing all the urls is not going to take too long and be too flaky. Have you considered that?
const expectedUrl = browser.baseUrl + url; | ||
const actualUrl = (await browser.getCurrentUrl()).replace(/\?.*$/, ''); | ||
|
||
expect(actualUrl).toBe(expectedUrl); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't we also verify that we didn't render an error or 404 page instead?
if you could add an assertion for the content of the doc-viewer DOM element I'd trust this test more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, while this would be nice, it would require waiting for the app to stabilize, which in turn would dramatically increase the total time (~5x).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case we should add these more expensive assertions just for a smaller sample of urls. maybe in a separate pr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created #23063 to track that. Let's land this and see how it works for a few days first.
039e44c
to
c2bcfe5
Compare
Pushed another fixup commit. Long running times are indeed a concern. After I realized I was doing an extra request per sitemap/legacy URL, the time for those tests was brought down to ~7.5mins (from ~17mins), which brings the overall time down to ~11mins per app URL. So, it would be ~22mins (plus setup time) for our two URLs (angular.io and next.angular.io), which sounds reasonable for this kind of job. If we want to reduce these times further, we could consider probing some of the URLs only. (But I would avoid randomness to retain reproducibility. Maybe we can test a subset of the URLs based on the current date or something.) I've not seen any flakeyness, when running this locally, so I think it is reasonable to not expect any more flakeyness that normally have on CI jobs 😁 |
You can preview c2bcfe5 at https://pr22483-c2bcfe5.ngbuilds.io/. |
This doesn't apply cleanly to the patch branch (conflicts with Rx pipeable operators update). Please split it into two PRs :) Thanks! |
This commit also waits for the app to stabilize, before starting to check for ServiceWorker updates. This avoids setting up a long timeout, which would prevent the app from stabilizing and thus cause issues with Protractor.
This commit prepares the ground for adding different types of tests.
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 angular#21942
f35dec6
to
a3000e2
Compare
OK. Let's merge this into master and I'll submit another PR for 5.2.x. |
This commit prepares the ground for adding different types of tests. PR Close #22483
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 issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Fix: Wait for the app to stabilize before registering the SW.
Wait for the app to stabilize, before registering the SW and starting to check for SW updates. This avoids setting up a long timeout, which would prevent the app from stabilizing and thus cause issues with Protractor.
Fix: Fix SW routing RegExp to allow redirecting
/api/animate
URLs.Prevent the SW from routing URLs starting with
/api/animate
toindex.html
. Instead, pass them through to the server, where they are correctly redirected.CI: Add monitoring for angular.io.
Configure 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.