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

tests: cron to check for relevant chromium changes #11763

Merged
merged 8 commits into from
Apr 13, 2021

Conversation

paulirish
Copy link
Member

We have two efforts where we have some risk if we fall behind Chromium.

  1. if devtools protocol adds new Issues types to the issues panel. aka Handle the unknown inspector issues #11530
  2. if the PWA installable_manager adds new error codes that we don't have installable-manifest strings for. (ref core(installable-manifest): use devtools InstallabilityErrors #11745)

i've been ruminating on some kinda test for a while and got these in a decent state.

to reviewers: the installability errors one is fairly grody, but it holds up fine and I don't think its worth it to parse the C++ into an AST or anything...

Setting on draft until #11745 lands and things quiet down a bit. no rush on this.

@paulirish paulirish requested a review from a team as a code owner December 4, 2020 08:15
@paulirish paulirish requested review from patrickhulce and removed request for a team December 4, 2020 08:15
@google-cla google-cla bot added the cla: yes label Dec 4, 2020
@paulirish paulirish marked this pull request as draft December 4, 2020 08:15
Copy link
Collaborator

@connorjclark connorjclark left a comment

Choose a reason for hiding this comment

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

@@ -24,3 +24,18 @@ jobs:
use-verbose-mode: 'yes'
Copy link
Collaborator

Choose a reason for hiding this comment

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

tying all these workflows to the same exact schedule seems brittle to me. Can we keep these as separate files?

Copy link
Collaborator

Choose a reason for hiding this comment

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

isn't this the only workflow on a schedule? consolidating to our "weekly" checks seems like a positive IMO

Copy link
Collaborator

Choose a reason for hiding this comment

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

node-version: 12.x
- run: yarn --frozen-lockfile

- name: yarn jest .github/test/*-uptodate-test.js
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think run: is just fine here.


it('are each handled explicitly in the gatherer', () => {
for (const inspectorIssueDetailsType of inspectorIssueDetailsTypes) {
expect(inspectorIssuesGathererSource.includes(inspectorIssueDetailsType)).toBeTruthy();
Copy link
Collaborator

@connorjclark connorjclark Dec 4, 2020

Choose a reason for hiding this comment

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

I'd suggest refactoring this gatherer to use (and export) a list of supported detail types (and then create the artifacts based on that list, instead of copying the same code for each case), but that approach was decided against in code review. this is kinda awk but no more than C++ regexes so WFM...

Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
expect(inspectorIssuesGathererSource.includes(inspectorIssueDetailsType)).toBeTruthy();
expect(inspectorIssuesGathererSource).toContain(inspectorIssueDetailsType);

will print out the contents if it can't find it :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Considering it's the entire source file, maybe not what we want :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

why not....

expect(false).toBeTruthy() doesn't seem better 😆

Copy link
Collaborator

Choose a reason for hiding this comment

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

Because the info you want from this test is "some value is missing". some useful info might be what the value is. but def dont want 100+ lines of code printed.

wb if (!inspectorIssuesGathererSource.includes(inspectorIssueDetailsType)) assert.fail('missing issue type ' + inspectorIssueDetailsType)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Because the info you want from this test is "some value is missing". some useful info might be what the value is.

you also get this information front and center with toContain, fwiw. for some logs that we don't really expect to fail that often ~80 lines of extra output doesn't seem that bad 🤷 though I must say I'm surprised coming from the same advocate of permanent verbose output in our smokes ;)

but ya I like your new suggestion too if your original proposal doesn't fly 👍

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

I like it 💯

*/
'use strict';

const assert = require('assert').strict;

This comment was marked as outdated.


it('are each handled explicitly in the gatherer', () => {
for (const inspectorIssueDetailsType of inspectorIssueDetailsTypes) {
expect(inspectorIssuesGathererSource.includes(inspectorIssueDetailsType)).toBeTruthy();
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
expect(inspectorIssuesGathererSource.includes(inspectorIssueDetailsType)).toBeTruthy();
expect(inspectorIssuesGathererSource).toContain(inspectorIssueDetailsType);

will print out the contents if it can't find it :)

});

it('should notify us if something changed', () => {
expect(chromiumErrorIds.sort()).toMatchInlineSnapshot(`
Copy link
Collaborator

Choose a reason for hiding this comment

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

sort it before? feels weird to mutate in a single it :)

});

it('are each handled explicitly in the gatherer', () => {
// expect.arrayContaining is semantically great, but the output sucks
Copy link
Collaborator

Choose a reason for hiding this comment

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

or...

Suggested change
// expect.arrayContaining is semantically great, but the output sucks
const errorStrings = Object.keys(InstallableManifestAudit.UIStrings)
.filter(key => chromiumErrorIds.includes(key))
.sort();
expect(errorStrings).toEqual(chromiumErrorIds);

for a nice one-shot output that lists all the missing ones? :)

@@ -24,3 +24,18 @@ jobs:
use-verbose-mode: 'yes'
Copy link
Collaborator

Choose a reason for hiding this comment

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

isn't this the only workflow on a schedule? consolidating to our "weekly" checks seems like a positive IMO

@@ -0,0 +1,47 @@
/**
Copy link
Collaborator

Choose a reason for hiding this comment

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

feels weird that these live in github though, aren't they effectively checks against our implementations and the github part is just an artifact of how frequently we want to run them?

Base automatically changed from dt-installable to master December 15, 2020 16:00
@connorjclark
Copy link
Collaborator

Still draft for a reason?

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

LGTM, I could go either way on the weekly thing so up to you and @connorjclark 👍

@paulirish
Copy link
Member Author

LGTM, I could go either way on the weekly thing so up to you and @connorjclark 👍

@connorjclark pr over to you

@connorjclark
Copy link
Collaborator

update with master + can you make sure it is still passing when run?

…s-test.js

Co-authored-by: Connor Clark <cjamcl@google.com>
@google-cla
Copy link

google-cla bot commented Mar 23, 2021

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

@google-cla google-cla bot added cla: no and removed cla: yes labels Mar 23, 2021
@paulirish paulirish force-pushed the chromium-tests-cron branch from 5eecc0a to 524257c Compare March 23, 2021 19:58
@google-cla google-cla bot added cla: yes and removed cla: no labels Mar 23, 2021
@connorjclark connorjclark changed the title tests: add weekly cron tests to confirm we're sync'd with chromium changes tests: cron to check for relevant chromium changes Apr 13, 2021
@connorjclark connorjclark merged commit f3bfb3c into master Apr 13, 2021
@connorjclark connorjclark deleted the chromium-tests-cron branch April 13, 2021 17:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants