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: run most smoke tests on devtools #13456

Merged
merged 37 commits into from
Jan 5, 2022
Merged

tests: run most smoke tests on devtools #13456

merged 37 commits into from
Jan 5, 2022

Conversation

connorjclark
Copy link
Collaborator

@connorjclark connorjclark commented Dec 2, 2021

Expanded yarn run-devtools:

  • Saves artifacts
  • Inject custom config
  • Some extra waiting to fix a bug where multiple launches of yarn run-devtools resulted in the script breaking

ref #13539
ref #13396

@connorjclark connorjclark requested a review from a team as a code owner December 2, 2021 23:00
@connorjclark connorjclark requested review from adamraine and removed request for a team December 2, 2021 23:00
@google-cla google-cla bot added the cla: yes label Dec 2, 2021
if (setupPromise) return setupPromise;

setupPromise = new Promise(resolve => {
// execFileSync('yarn', ['open-devtools']);
Copy link
Collaborator Author

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?

Copy link
Member

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.

Copy link
Member

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?

Copy link
Collaborator Author

@connorjclark connorjclark Jan 4, 2022

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.

Copy link
Collaborator Author

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

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.

.github/workflows/devtools.yml Outdated Show resolved Hide resolved
const args = [
'run-devtools',
url,
'--output-dir', outputDir,
Copy link
Member

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.

Copy link
Collaborator Author

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.

lighthouse-core/scripts/pptr-run-devtools.js Show resolved Hide resolved
@@ -73,3 +73,18 @@ jobs:
with:
name: results
path: ${{ github.workspace }}/lighthouse/.tmp/layout-test-results

# Run smoke tests via DevTools
Copy link
Member

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?

Copy link
Collaborator Author

@connorjclark connorjclark Dec 3, 2021

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?

Copy link
Member

@brendankenny brendankenny Jan 5, 2022

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

.github/workflows/devtools.yml Outdated Show resolved Hide resolved
if (setupPromise) return setupPromise;

setupPromise = new Promise(resolve => {
// execFileSync('yarn', ['open-devtools']);
Copy link
Member

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?

@brendankenny
Copy link
Member

this is great!

const targetManager =
SDK.targetManager || (SDK.TargetManager.TargetManager || SDK.TargetManager).instance();
if (targetManager.mainTarget() === null) {
if (targetManager.observeTargets) {
Copy link
Member

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?

Copy link
Collaborator Author

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 😬

lighthouse-core/scripts/pptr-run-devtools.js Outdated Show resolved Hide resolved
Copy link
Member

@adamraine adamraine left a 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.
Copy link
Member

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

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?

Copy link
Member

@brendankenny brendankenny Jan 5, 2022

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

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

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?

Copy link
Collaborator Author

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.

Copy link
Member

@brendankenny brendankenny Jan 5, 2022

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

@connorjclark connorjclark changed the title tests: run smokehouse on devtools tests: run most smoke tests on devtools Jan 5, 2022
@@ -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);
Copy link
Member

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

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?

Copy link
Collaborator Author

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

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

Choose a reason for hiding this comment

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

maybe

Suggested change
let beforeAllPromise;
let buildDevtoolsPromise;

or something like that?


/** @type {Promise<void>} */
let beforeAllPromise;
async function beforeAll() {
Copy link
Member

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

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.

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