Skip to content
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

aio: add monitoring and fix a couple of issues #22483

Closed
wants to merge 10 commits into from

Conversation

gkalpak
Copy link
Member

@gkalpak gkalpak commented Feb 27, 2018

  • 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 to index.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.

@gkalpak gkalpak added type: bug/fix area: build & ci Related the build and CI infrastructure of the project action: review The PR is still awaiting reviews from at least one requested reviewer comp: aio target: patch This PR is targeted for the next patch release labels Feb 27, 2018
@gkalpak gkalpak added this to REVIEW in docs-infra Feb 27, 2018
@mary-poppins
Copy link

You can preview 676a999 at https://pr22483-676a999.ngbuilds.io/.

Copy link
Member

@petebacondarwin petebacondarwin left a 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();
Copy link
Member

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);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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()
Copy link
Member

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)

Copy link
Member Author

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(() => {
Copy link
Member

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';
Copy link
Member

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...

Copy link
Member

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

Copy link
Member Author

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.
Copy link
Member

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?

Copy link
Member Author

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).

Copy link
Member

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?

Copy link
Member Author

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 😁

Copy link
Member

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.

Copy link
Member Author

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.)

Copy link
Member Author

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",
Copy link
Member

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?

Copy link
Member Author

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() {
Copy link
Member

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.

@petebacondarwin petebacondarwin added action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Feb 28, 2018
@mary-poppins
Copy link

You can preview 7873194 at https://pr22483-7873194.ngbuilds.io/.

@mary-poppins
Copy link

You can preview 9148010 at https://pr22483-9148010.ngbuilds.io/.

@gkalpak gkalpak force-pushed the ci-aio-monitoring branch 2 times, most recently from c3a91a8 to 52ceab0 Compare February 28, 2018 19:23
@gkalpak
Copy link
Member Author

gkalpak commented Feb 28, 2018

@petebacondarwin, I added a bunch of fixup commits. (I didn't touch the non-fixup commits other than rebasing on master.) PTAL

@mary-poppins
Copy link

You can preview 52ceab0 at https://pr22483-52ceab0.ngbuilds.io/.

@gkalpak gkalpak requested a review from IgorMinar March 1, 2018 12:24
@gkalpak gkalpak added action: review The PR is still awaiting reviews from at least one requested reviewer and removed action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews labels Mar 1, 2018
Copy link
Contributor

@IgorMinar IgorMinar left a 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);
Copy link
Contributor

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.

Copy link
Member Author

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).

Copy link
Contributor

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?

Copy link
Member Author

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.

@IgorMinar IgorMinar added action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Mar 2, 2018
@gkalpak gkalpak force-pushed the ci-aio-monitoring branch 2 times, most recently from 039e44c to c2bcfe5 Compare March 5, 2018 13:36
@gkalpak
Copy link
Member Author

gkalpak commented Mar 5, 2018

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 😁
But, only time will tell for sure 🤔

@alxhub alxhub added action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews and removed action: merge The PR is ready for merge by the caretaker labels Mar 29, 2018
@alxhub
Copy link
Member

alxhub commented Mar 29, 2018

This doesn't apply cleanly to the patch branch (conflicts with Rx pipeable operators update). Please split it into two PRs :) Thanks!

@gkalpak gkalpak added target: major This PR is targeted for the next major release and removed target: patch This PR is targeted for the next patch release labels Mar 30, 2018
@gkalpak gkalpak added action: merge The PR is ready for merge by the caretaker and removed action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews labels Mar 30, 2018
@gkalpak
Copy link
Member Author

gkalpak commented Mar 30, 2018

OK. Let's merge this into master and I'll submit another PR for 5.2.x.
(EDIT: #23093 for 5.2.x)

@alxhub alxhub closed this in 8c10df3 Mar 30, 2018
alxhub pushed a commit that referenced this pull request Mar 30, 2018
This commit prepares the ground for adding different types of tests.

PR Close #22483
alxhub pushed a commit that referenced this pull request Mar 30, 2018
alxhub pushed a commit that referenced this pull request Mar 30, 2018
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
@gkalpak gkalpak deleted the ci-aio-monitoring branch April 2, 2018 07:13
@gkalpak gkalpak removed this from REVIEW in docs-infra Apr 2, 2018
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: build & ci Related the build and CI infrastructure of the project cla: yes target: major This PR is targeted for the next major release type: bug/fix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

aio: add regular e2e testing of angular.io
6 participants