Moved from #1055.
Next steps 06/01 15:15
#1093 addressed the immediate problems named here, so this issue is now an enhancement, not a priority or bug. To fully resolve, I'd like to see if we can get to a point where we're not trying to locate the browser executable ourselves. My next suggestion is to work out all the issues that new versions of puppeteer would cause and resolve those up to the most recent (minus 7 days) version of puppeteer.
Decision
We are going to automate ALKiln internal security with .npmrc and [still use npm install because npm ci can't be used for a global package] use npm ci both in our own code and in consumer-facing code. Since our dependencies are pinned with npm shrinkwrap, out consumers will benefit from those measures as well. ALKiln's code itself doesn't have the kind of pipeline (that is, thousands of consumers or more) that would catch breaches in the same way that hugely popular packages do, so a 7-day delay in the version of ALKiln itself has very little impact, so we will remove --min-age-release from the action, and maybe from ALKiP as well. We may also remove --ignore-scripts from consumer-run code for the same reasons. [Our own --ignore-scripts won't protect consumers from malicious scripts, so we will continue to use --ignore-scripts in code that others consume.]
Summary 05/29, 13:30
GitHub workflows using our action are unable to find and install Chrome when they install ALKiln (the package in this repo). Even workflows from the past few days that previously were able to find Chrome (such as this workflow, failing for unrelated reasons) and run Chrome for the tests, are now failing to find Chrome (here's a second run of the previously linked workflow). I've only managed to trigger this behavior on GitHub, not in a locally installed version of Docassemble (which uses ALKilnInThePlayground to install ALKiln. Other distractions are all over the place, but the fact that new runs behave differently than old runs leads me to believe something has changed about the environment. The current possible culprits I can think of are GitHub, puppeteer, and docassemble. Docassemble hasn't changed recently, nor has docassemble-os.]
Previous updates, most recent first
05/29 17:00
One theory was that the Chrome binary became unavailable, but I'm able to download Chrome at https://storage.googleapis.com/chrome-for-testing-public/127.0.6533.88/linux64/chrome-linux64.zip. Also, a simplified version of the action (that just installs puppeteer) is able to run without error.
Another test I ran in our package on our current default branch (--ignore-scripts and rebuild ... --update-binaries) ran npm install ... fine and then later failed the tests because it was unable to find Chrome during the test run. All these different presentations are unhelpful.
05/29 10:35
Installing locally on a docassemble server with -g has no problem. Our GitHub test that previously was able to run tests (unrelated error) fail on a rerun, now unable to download Chrome.
05/28 10:55
I believe we're now running into an unrelated issue where Chrome isn't downloading:
added 362 packages in 11s
67 packages are looking for funding
run npm fund for details
npm error code 1
npm error path /opt/hostedtoolcache/node/24.16.0/x64/lib/node_modules/@suffolklitlab/alkiln/node_modules/puppeteer
npm error command failed
npm error command sh -c node install.mjs
npm error Error: ERROR: Failed to set up Chrome v127.0.6533.88!
Not sure why. (Ignore the exclamation points. They're supposed to be there.) On this page about Chrome at uptodown it lists individual releases, but the version of Chrome we're trying to download doesn't appear in those releases if you "load more" versions a few times:
Thank you @inkwell-eye. We're not sure if it's definitive.
A post on GitHub from 2024 with the same problem ([Bug]: Error: Could not find Chrome (ver. 127.0.6533.88).) suggests alternative ways to hunt down the problem that we will try.
Note that the puppeteer chrome installation part of our code has worked for us for quite a while, including after 2024, and including earlier today (erroring for a different reason).
Moved from #1055.
Next steps 06/01 15:15
#1093 addressed the immediate problems named here, so this issue is now an enhancement, not a priority or bug. To fully resolve, I'd like to see if we can get to a point where we're not trying to locate the browser executable ourselves. My next suggestion is to work out all the issues that new versions of puppeteer would cause and resolve those up to the most recent (minus 7 days) version of puppeteer.
Decision
We are going to automate ALKiln internal security with
.npmrcand [still usenpm installbecausenpm cican't be used for a global package]useboth in our own code and in consumer-facing code. Since our dependencies are pinned with npm shrinkwrap, out consumers will benefit from those measures as well. ALKiln's code itself doesn't have the kind of pipeline (that is, thousands of consumers or more) that would catch breaches in the same way that hugely popular packages do, so a 7-day delay in the version of ALKiln itself has very little impact, so we will removenpm ci--min-age-releasefrom the action, and maybe from ALKiP as well.We may also remove[Our own--ignore-scriptsfrom consumer-run code for the same reasons.--ignore-scriptswon't protect consumers from malicious scripts, so we will continue to use--ignore-scriptsin code that others consume.]Summary 05/29, 13:30
GitHub workflows using our action are unable to find and install Chrome when they install ALKiln (the package in this repo). Even workflows from the past few days that previously were able to find Chrome (such as this workflow, failing for unrelated reasons) and run Chrome for the tests, are now failing to find Chrome (here's a second run of the previously linked workflow). I've only managed to trigger this behavior on GitHub, not in a locally installed version of Docassemble (which uses ALKilnInThePlayground to install ALKiln. Other distractions are all over the place, but the fact that new runs behave differently than old runs leads me to believe something has changed about the environment. The current possible culprits I can think of are GitHub, puppeteer, and docassemble. Docassemble hasn't changed recently, nor has docassemble-os.]
Previous updates, most recent first
05/29 17:00
One theory was that the Chrome binary became unavailable, but I'm able to download Chrome at https://storage.googleapis.com/chrome-for-testing-public/127.0.6533.88/linux64/chrome-linux64.zip. Also, a simplified version of the action (that just installs puppeteer) is able to run without error.
Another test I ran in our package on our current default branch (
--ignore-scriptsandrebuild ... --update-binaries) rannpm install ...fine and then later failed the tests because it was unable to find Chrome during the test run. All these different presentations are unhelpful.05/29 10:35
Installing locally on a docassemble server with -g has no problem. Our GitHub test that previously was able to run tests (unrelated error) fail on a rerun, now unable to download Chrome.
05/28 10:55
I believe we're now running into an unrelated issue where Chrome isn't downloading:
Not sure why. (Ignore the exclamation points. They're supposed to be there.) On this page about Chrome at uptodown it lists individual releases, but the version of Chrome we're trying to download doesn't appear in those releases if you "load more" versions a few times:
Thank you @inkwell-eye. We're not sure if it's definitive.
A post on GitHub from 2024 with the same problem ([Bug]: Error: Could not find Chrome (ver. 127.0.6533.88).) suggests alternative ways to hunt down the problem that we will try.
Note that the puppeteer chrome installation part of our code has worked for us for quite a while, including after 2024, and including earlier today (erroring for a different reason).