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

CI failing in UI build #81

Closed
oddhack opened this issue Apr 29, 2024 · 3 comments
Closed

CI failing in UI build #81

oddhack opened this issue Apr 29, 2024 · 3 comments
Assignees
Labels
bug Something isn't working process meta-issues for builds, external dependencies, etc.
Milestone

Comments

@oddhack
Copy link
Collaborator

oddhack commented Apr 29, 2024

@gpx1000 could you take a look at recent Actions runs like https://github.com/KhronosGroup/Vulkan-Site/actions/runs/8877551920/job/24371369290 and offer any insight you may have? There is a failure in the UI build which I am unable to replicate locally, and additionally, it's a retroactive failure - CI runs which previously succeeded, like https://github.com/KhronosGroup/Vulkan-Site/actions/runs/8762534741, failed in the same way when I re-ran their jobs.

I suspect that some npm package dependency has changed in a fatal fashion, possibly by being obsoleted or removed. There are many warnings about deprecation and obsoletion but really, there always are so I have not worried about them until now.

If you don't see something obvious, my thought is to re-sync the UI repository with the Antora upstream, which hasn't been done since last fall sometime. That may not be straightforward but should be done periodically, anyway and should at least reduce the warnings.

@oddhack oddhack added bug Something isn't working process meta-issues for builds, external dependencies, etc. labels Apr 29, 2024
@oddhack oddhack added this to the Needs Triage milestone Apr 29, 2024
@oddhack
Copy link
Collaborator Author

oddhack commented Apr 29, 2024

@gpx1000 I'm very unsophisticated where npm is concerned, but am wondering if it's feasible to lock all the packages to specific versions that are collectively known to work at some time, and only rarely update that when forced by external events (such as this, possibly)? I don't think that's happening now as I see comments in the CI logs about various components being updated. This is much the same reason I prefer using a known-good Docker image for the regular spec builds - there are just so many different toolchain bits in so many different languages and package managers and having to go out to the net every time is a potential failure point. IMO ideally we can eventually have a variant of the Docker image that has all npm packages preinstalled and no requirement whatsoever for npm updates, just start the image and run the build from that.

@oddhack
Copy link
Collaborator Author

oddhack commented Apr 30, 2024

I think I've tracked this down to nodejs/node#52708 / gulpjs/vinyl-fs#350 . TL;DR nodejs 22 has a bug which the gulp.js/vinyl-fs package triggers. It will be some time before a new node is published and in the meantime, I found a recommendation for backing off to node 21.7.3, though perhaps the LTS 20.12.2 would be better? I am going to attempt this in CI and see what happens. N.b. my local install is running node 20.10.0 which probably explains why it's working.

@gpx1000 perhaps we should as a general matter not use 'latest' node in CI? If we switch to a known-good LTS version lock in the "setup npm" step and only occasionally upgrade it as it gets too old, that will be a periodic annoyance but less so than diagnosing this sort of problem.

@oddhack
Copy link
Collaborator Author

oddhack commented Apr 30, 2024

Fixed by #83, which locks CI to using node 20.12.2.

@oddhack oddhack closed this as completed Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working process meta-issues for builds, external dependencies, etc.
Projects
None yet
Development

No branches or pull requests

2 participants