-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
Conversation
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.
@@ -24,3 +24,18 @@ jobs: | |||
use-verbose-mode: 'yes' |
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.
tying all these workflows to the same exact schedule seems brittle to me. Can we keep these as separate files?
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.
isn't this the only workflow on a schedule? consolidating to our "weekly" checks seems like a positive IMO
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.
.github/workflows/cron-weekly.yml
Outdated
node-version: 12.x | ||
- run: yarn --frozen-lockfile | ||
|
||
- name: yarn jest .github/test/*-uptodate-test.js |
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 think run:
is just fine here.
|
||
it('are each handled explicitly in the gatherer', () => { | ||
for (const inspectorIssueDetailsType of inspectorIssueDetailsTypes) { | ||
expect(inspectorIssuesGathererSource.includes(inspectorIssueDetailsType)).toBeTruthy(); |
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'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...
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.
expect(inspectorIssuesGathererSource.includes(inspectorIssueDetailsType)).toBeTruthy(); | |
expect(inspectorIssuesGathererSource).toContain(inspectorIssueDetailsType); |
will print out the contents if it can't find 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.
Considering it's the entire source file, maybe not what we want :)
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.
why not....
expect(false).toBeTruthy()
doesn't seem better 😆
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.
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)
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.
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 👍
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 like it 💯
*/ | ||
'use strict'; | ||
|
||
const assert = require('assert').strict; |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
||
it('are each handled explicitly in the gatherer', () => { | ||
for (const inspectorIssueDetailsType of inspectorIssueDetailsTypes) { | ||
expect(inspectorIssuesGathererSource.includes(inspectorIssueDetailsType)).toBeTruthy(); |
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.
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(` |
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.
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 |
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.
or...
// 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' |
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.
isn't this the only workflow on a schedule? consolidating to our "weekly" checks seems like a positive IMO
@@ -0,0 +1,47 @@ | |||
/** |
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.
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?
4311e98
to
00e3b28
Compare
Still draft for a reason? |
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.
LGTM, I could go either way on the weekly
thing so up to you and @connorjclark 👍
@connorjclark pr over to you |
third-party/chromium-synchronization/inspector-issueAdded-types-test.js
Outdated
Show resolved
Hide resolved
update with master + can you make sure it is still passing when run? |
…s-test.js Co-authored-by: Connor Clark <cjamcl@google.com>
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 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 ℹ️ Googlers: Go here for more info. |
5eecc0a
to
524257c
Compare
We have two efforts where we have some risk if we fall behind Chromium.
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.