andygrove commented on PR #6064: URL: https://github.com/apache/datafusion-comet/pull/6064#issuecomment-5750729720
Both causes are now pinned down empirically rather than inferred, and they are different on the two runners. **The docs deploy, `ubuntu-24.04`.** I ran the deploy's exact mermaid steps on a throwaway branch on my fork, as a two-arm matrix: one arm with the `--no-sandbox` puppeteer config this PR adds, one with `mermaid_params` reverted to what is on main today. | arm | result | | --- | --- | | with `puppeteer-config.json` | all 3 diagrams render | | `mermaid_params = ['-b', 'transparent']` (main today) | fails | and the failing arm says it outright: ``` [FATAL:content/browser/zygote_host/zygote_host_impl_linux.cc:129] No usable sandbox! If you are running on Ubuntu 23.10+ or another Linux distro that has disabled unprivileged user namespaces with AppArmor, see .../apparmor-userns-restrictions.md. ... If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox. ``` So that is #6062's root cause, confirmed: Chrome cannot start on the deploy runner, mmdc exits non-zero, `sphinxcontrib-mermaid` turns it into a warning, and the page publishes without the diagram. The probe branch is deleted. **Preflight, `ubuntu-slim`.** Different failure, and one this PR introduced by rendering somewhere new: the slim image carries none of Chrome's shared libraries, so the browser downloads and then dies on `libatk-1.0.so.0: cannot open shared object file`. Fixed by installing what `chrome-headless-shell` links against; preflight is green now. Worth noting how that second one was diagnosed, because it is the reason for the last commit: the first CI run reproduced the failure but the annotation said only "mmdc cannot render this diagram", and GitHub-hosted job logs are not always reachable. The check now puts mmdc's full stderr in the annotation, which is what made both of these readable without opening a log. **Cost.** Preflight goes from ~1m to 2m24s: 80s for the apt packages, npm install and browser fetch, 7s for the three renders. If that is too much for every pull request, the alternatives are to cache `~/.cache/puppeteer` (restore on PRs, save on main, ~30s back) or to drop the preflight half entirely and rely on the deploy-side check, which is the one that actually blocks a bad publish. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
