CI failing in UI build

[oddhack]

@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]

@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]

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]

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