Re-enable CI runs for Windows on Puppeteer repository
Categories
(Remote Protocol :: CDP, enhancement, P2)
Tracking
(firefox90 fixed)
Tracking | Status | |
---|---|---|
firefox90 | --- | fixed |
People
(Reporter: whimboo, Assigned: whimboo)
References
Details
(Whiteboard: [bidi-m1-mvp])
Attachments
(1 file)
Currently Puppeteer doesn't run the unit tests on Windows due to problems with shutting down the browser. See bug 1656962. For getting out of the experimental status we should get the tests running again on Windows.
The following PR will make it happen:
https://github.com/puppeteer/puppeteer/pull/6895
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #0)
The following PR will make it happen:
https://github.com/puppeteer/puppeteer/pull/6895
The most recent patch works as expected and the PR is now under review.
Assignee | ||
Comment 2•4 years ago
|
||
We won't need bug 1656962 to make it work.
Assignee | ||
Comment 3•4 years ago
|
||
https://github.com/puppeteer/puppeteer/pull/6895 has been merged.
Assignee | ||
Comment 4•4 years ago
|
||
I will reopen this bug to get the upstream change synced to mozilla-central given that it was not part of the v8.0.0 release.
Assignee | ||
Comment 5•4 years ago
|
||
Updated•4 years ago
|
Comment 7•4 years ago
|
||
bugherder |
Comment 8•4 years ago
|
||
Backed out changeset 4d29ba47da66 (bug 1693763) for causing Bug 1701960. CLOSED TREE
https://hg.mozilla.org/integration/autoland/rev/7e1c207a752cccb9917cafacb40434cdf698e073
Comment 9•4 years ago
|
||
I investigated the failures for "Launcher specs Puppeteer Puppeteer.launch should be able to launch Firefox (launcher.spec.ts)"
From what I can tell, the test will pass as long as you first properly installed puppeteer, including the firefox dependency.
Run:
cd remote/test/puppeteer
PUPPETEER_PRODUCT=firefox npm i
After that the test passes successfully.
It's also something that puppeteer CI does: https://github.com/puppeteer/puppeteer/blob/main/.github/workflows/main.yml#L35
On try, we set the current path to the Firefox binary in executablePath
to avoid downloading any binary.
But this test asserts await puppeteer.launch({ product: 'firefox' });
, which is by definition not using executablePath
(I think it needs to be explicitly passed via something like await puppeteer.launch({ executablePath });
).
It seems to me that for the time being we should expect this launcher test to FAIL on Try.
Should we reland this patch, but change the expectation to FAIL?
Comment 10•4 years ago
|
||
Backout merged: https://hg.mozilla.org/mozilla-central/rev/7e1c207a752c
Comment 11•4 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:whimboo, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 12•4 years ago
|
||
(In reply to Julian Descottes [:jdescottes] from comment #9)
It seems to me that for the time being we should expect this launcher test to FAIL on Try.
Should we reland this patch, but change the expectation to FAIL?
Good find! And it sounds good. I will update the patch shortly. Would you mind to file a new bug for your findings?
Assignee | ||
Comment 13•4 years ago
|
||
Actually I made a mistake in the upstream patch:
https://github.com/puppeteer/puppeteer/blob/cf8c08d9919c5ab5247e23d55bbbc2ac4e48215f/test/launcher.spec.ts#L450
It should not be it
but itOnlyRegularInstall
similar to what is used for Chrome. In such a case this test will just be skipped.
Assignee | ||
Comment 14•4 years ago
|
||
I created a follow-up PR upstream: https://github.com/puppeteer/puppeteer/pull/7106
Comment 15•4 years ago
|
||
Comment 16•4 years ago
|
||
bugherder |
Description
•