-
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: run most smoke tests on devtools #13456
Conversation
if (setupPromise) return setupPromise; | ||
|
||
setupPromise = new Promise(resolve => { | ||
// execFileSync('yarn', ['open-devtools']); |
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.
TODO: I thought about doing the setup for building ToT devtools here... would that be useful?
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.
Yeah, otherwise we're only testing whatever Lighthouse is shipped in Chrome.
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.
TODO: I thought about doing the setup for building ToT devtools here... would that be useful?
yeah, though it would be nice if it didn't attempt to re-update on every run. Is it currently only the content-shell we only update every X commits?
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.
The GHA workflow already builds devtools before starting this smoke test as part of the layout tests ... so let's do something here but only for local runs.
export DEVTOOLS_PATH=".tmp/chromium-web-tests/devtools/devtools-frontend"
bash lighthouse-core/test/chromium-web-tests/download-devtools.sh
bash lighthouse-core/test/chromium-web-tests/roll-devtools.sh
(and then the local devtools smoke run would defer to w/e CHROME_PATH you have, not use the latest content shell ... unless thats your chrome path.)
# | ||
# Run `yarn test-devtools` first to update the temporary devtools checkout. | ||
# Specify `$DEVTOOLS_PATH` to use a different devtools repo. | ||
|
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.
some driveby extra documentation
if (setupPromise) return setupPromise; | ||
|
||
setupPromise = new Promise(resolve => { | ||
// execFileSync('yarn', ['open-devtools']); |
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.
Yeah, otherwise we're only testing whatever Lighthouse is shipped in Chrome.
const args = [ | ||
'run-devtools', | ||
url, | ||
'--output-dir', outputDir, |
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.
We could use the custom DT frontend flag to test how PR changes affect DT.
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.
Ah, I keep making this mistake, thinking that is the default behavior. It is for open-devtools! I want to followup with a change that does that.
Will add the arg here for now.
@@ -73,3 +73,18 @@ jobs: | |||
with: | |||
name: results | |||
path: ${{ github.workspace }}/lighthouse/.tmp/layout-test-results | |||
|
|||
# Run smoke tests via DevTools |
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.
Better in a new job?
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.
How to avoid redoing all the work for building devtools?
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.
How to avoid redoing all the work for building devtools?
Yeah it's not pretty. We could have dependent jobs (or cache the build, but dependent jobs seems workable)? I'm not sure of the best approach, but if the devtools CI job is normally going to take 30+ minutes we'll definitely want to split it up.
edit: if an already-built devtools was available, sharding would work as well
if (setupPromise) return setupPromise; | ||
|
||
setupPromise = new Promise(resolve => { | ||
// execFileSync('yarn', ['open-devtools']); |
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.
TODO: I thought about doing the setup for building ToT devtools here... would that be useful?
yeah, though it would be nice if it didn't attempt to re-update on every run. Is it currently only the content-shell we only update every X commits?
this is great! |
const targetManager = | ||
SDK.targetManager || (SDK.TargetManager.TargetManager || SDK.TargetManager).instance(); | ||
if (targetManager.mainTarget() === null) { | ||
if (targetManager.observeTargets) { |
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.
When would this be falsy? In an older version of DT?
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.
Could be. It was pretty involved making sure a bunch of older chromes worked with this script, so I am doing without testing if it is necessary 😬
…tools smoke runner
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
# TODO: run on all tests. | ||
# - Current DevTools hangs on any page with a service worker. | ||
# https://github.com/GoogleChrome/lighthouse/issues/13396 | ||
# - Various other issues that needed investigation. |
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 you create an issue to track this second bullet?
* @return {Promise<{lhr: LH.Result, artifacts: LH.Artifacts, log: string}>} | ||
*/ | ||
async function runLighthouse(url, configJson, testRunnerOptions = {}) { | ||
const outputDir = fs.mkdtempSync(os.tmpdir() + '/lh-smoke-cdt-runner-'); |
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.
Does this create multiple temp directories if the smokes are running concurrently?
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.
yeah, fs.mkdtempSync
handles that
@@ -146,8 +151,19 @@ async function runSmokeTest(smokeTestDefn, testOptions) { | |||
|
|||
// Run Lighthouse. | |||
try { | |||
/** @type {NodeJS.Timeout} */ | |||
let timeout; |
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 mentioned this out of band, but for tracking here:
This adds some timeout redundancy here, since Lighthouse itself will also fail with an error after it times out, which leaves it somewhat unclear where modified timeouts should be specified, here or in the runners. It's not a huge deal, (100s is pretty long, so the core Lighthouse one will always end first), but simplicity-wise it might make sense to move this timeout into the new devtools.js
and leave runs with the other runners unchanged.
This was mostly a nit before, but the introduction of beforeAll
makes it a bigger win simplicity-wise, since devtools.js
wouldn't need a beforeAll
at that point, it could just call those lines itself and just exempt them from the overall timeout.
}); | ||
spawnHandle.on('error', reject); | ||
spawnHandle.stdout.on('data', data => { | ||
console.log(data.toString()); |
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 these lines intended to stay or for debugging?
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, otherwise the cases where things hang or error aren't printed (the runner interface only allows returning successful logs). and it's nicer to see the output stream in.
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.
just checking that it's intentional. The tradeoff is that concurrent runs will be streaming in stuff all interleaved with each other and hard to tell the source of each line, but that can still be helpful, especially when things are new and need to check that it's actually running, etc
@@ -183,7 +184,7 @@ async function begin() { | |||
if (argv.runner === 'bundle') { | |||
console.log('\n✨ Be sure to have recently run this: yarn build-all'); | |||
} | |||
const {runLighthouse} = await import(runnerPath); | |||
const {runLighthouse, beforeAll} = await import(runnerPath); |
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 remove beforeAll (here and in types/smokehouse.d.ts
)
if (self.runtime && self.runtime.loadLegacyModule) { | ||
// This exposes TargetManager via self.SDK. | ||
try { | ||
await self.runtime.loadLegacyModule('core/sdk/sdk-legacy.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 don't know the DT story here) does the "legacy" part of this path mean this is going to go away at some point?
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.
Sure hope not, otherwise I found no way to access TargetManager!
@@ -155,6 +190,35 @@ async function testPage(page, browser, url) { | |||
.catch(reject); | |||
}); | |||
|
|||
if (config) { | |||
// Must attach to the Lighthouse worker target and override the `self.createConfig` |
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.
haha, this should maybe be a TODO as well, some easier way to set a config :)
} | ||
|
||
/** @type {Promise<void>} */ | ||
let beforeAllPromise; |
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.
maybe
let beforeAllPromise; | |
let buildDevtoolsPromise; |
or something like that?
|
||
/** @type {Promise<void>} */ | ||
let beforeAllPromise; | ||
async function beforeAll() { |
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 you add a jsdoc like, "Build the lighthouse DevTools bundle and fetch and build the DevTools frontend using it" or whatever?
} | ||
|
||
/** | ||
* Launch Chrome and do a full Lighthouse run via DevTools. |
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'm having trouble coming up with a non-awkward way to say this, but seems worth clarifying it's the current/local Lighthouse devtools bundle run in the latest DevTools frontend
vs
latest DevTools frontend with whatever Lighthouse version was last rolled into Chromium.
Expanded
yarn run-devtools
:yarn run-devtools
resulted in the script breakingref #13539
ref #13396