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(viewer): don't override puppeteer's chromium #9877

Merged
merged 11 commits into from
Oct 24, 2019

Conversation

connorjclark
Copy link
Collaborator

This test is currently failing in master.

The viewer's puppeteer test doesn't work with Chrome 78, and neither does the latest puppeteer (1.20.0).

Puppeteer ships with a specific Chromium revision, and is only meant to work with that, so we shouldn't override it.

This test is currently failing in master.

The viewer's puppeteer test doesn't work with Chrome 78, and neither does the latest puppeteer (1.20.0).

Puppeteer ships with a specific Chromium revision, and is only meant to work with that, so we shouldn't override it.
@patrickhulce
Copy link
Collaborator

that didn't seem to do the trick yet

viewer tests failed with

Chromium revision is not downloaded. Run "npm install" or "yarn install"

@connorjclark
Copy link
Collaborator Author

MaybeTravis doesn't clear env variables between runs?

@brendankenny
Copy link
Member

Puppeteer ships with a specific Chromium revision, and is only meant to work with that, so we shouldn't override it.

this was partly to avoid redownloading Chromium every time (it may have been skipping node_modules/ caching since pptr downloads it itself on install?) and making the travis runs even slower. Ideally someone in the world has figured that out since #4640?

Otherwise, is there something specific that broke with m78 and is it something we can get fixed upstream? pptr is going to have to update its version of Chromium at some point...

@connorjclark
Copy link
Collaborator Author

Otherwise, is there something specific that broke with m78 and is it something we can get fixed upstream? pptr is going to have to update its version of Chromium at some point...

@mathiasbynens might know. We could bisect it.

@connorjclark
Copy link
Collaborator Author

tools/bisect-builds.py --use-local-cache -a linux64 -g 674921 -b 693954 --not-interactive -c 'bash -c "cd ~/code/lighthouse && CHROME_PATH=%p yarn jest viewer -t PSI"' --verify-range

Can't get the bad revision (693954 is current stable) to fail, even though using the stable channel binary directly does fail. Weird.

This reverts commit ca383f5.
@connorjclark
Copy link
Collaborator Author

For travis, had to unset the puppeteer env variable. I guess it stuck around from previous runs.

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.

love that green build :)

a major bummer to our build times but a necessary evil to be able to keep merging I suppose

# with the latest puppeteer api so we probably need to run on chromimum
# @see https://github.com/GoogleChrome/lighthouse/pull/4640/files#r171425004
- export PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=1
- unset PUPPETEER_SKIP_CHROMIUM_DOWNLOAD
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm assuming can we remove this 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.

yeah, but can't be sure at what point. unless someone wants to merge master into ever outstanding PR branch after this lands.

It sure is unexpected that environment variables seem to persist.

Copy link
Member

@brendankenny brendankenny Oct 24, 2019

Choose a reason for hiding this comment

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

we might need to just clear the caches. If we keep this we should also leave a comment similar to the removed one for why this is being unset :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Clearing cache didn't help, I tried that first.

Copy link
Member

Choose a reason for hiding this comment

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

environment variables seem to persist

I just don't see how this makes sense. It seems like people would be constantly running into it.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe b/c we should have use env: instead of a manual export?

@connorjclark
Copy link
Collaborator Author

a major bummer to our build times but a necessary evil to be able to keep merging I suppose

We could consider removing the other Chrome install, and just use Puppeteer's instead. We would have to manage updating Puppeteer on a regular basis. note: I don't love this idea.

@mathiasbynens
Copy link
Member

Can't get the bad revision (693954 is current stable) to fail, even though using the stable channel binary directly does fail. Weird.

This sounds super weird indeed... I wonder what we're missing?

We could consider removing the other Chrome install, and just use Puppeteer's instead. We would have to manage updating Puppeteer on a regular basis. note: I don't love this idea.

FWIW, we're committed to cutting a new Puppeteer release for every Chrome milestone (at the very least). Managing the major Chrome versions through whatever the latest Puppeteer requires seems like the way to go, imho.

@connorjclark
Copy link
Collaborator Author

One unexpected thing is that https://omahaproxy.appspot.com/ gives me 78.0.3904.70 as the stable version and 693954 as its base revision, but when the bisect script downloads 693954 it's actually version 78.0.3904.0.

tools/bisect-builds.py --use-local-cache -a mac -g 674921 -b 693954 --not-interactive -c '%p --version' --verify-range

image

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

does it work with the new 2.0.0 pptr release?

# with the latest puppeteer api so we probably need to run on chromimum
# @see https://github.com/GoogleChrome/lighthouse/pull/4640/files#r171425004
- export PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=1
- unset PUPPETEER_SKIP_CHROMIUM_DOWNLOAD
Copy link
Member

@brendankenny brendankenny Oct 24, 2019

Choose a reason for hiding this comment

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

we might need to just clear the caches. If we keep this we should also leave a comment similar to the removed one for why this is being unset :)

@connorjclark
Copy link
Collaborator Author

does it work with the new 2.0.0 pptr release?

I don't think it will, since the issue is with Chromium and not Puppeteer. Let's see: #9886

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

well, 🤷. At least it'll work now :)

LGTM

@connorjclark connorjclark merged commit 4e11bd2 into master Oct 24, 2019
@connorjclark connorjclark deleted the connorjclark-patch-1 branch October 24, 2019 21:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants