Yeah I had thought about that — but at the time of day when I had been trying it on the 16th locally and Bikeshed was using the 15th as the date, it was actually already the 16th in UTC time too

Anyway, I resorted to just putting Date: now in the .bs source, and that made Bikeshed stop putting the wrong, previous-day date

TabAtkins: For bikeshed echidna, are you aware of any (previous) cases where the W3C service has been unable to extract the generated tar file?

In particular, for jobs running user GitHub Actions?

I have a reproducible case where:

• locally (in my macOS environment) when I use bikeshed echidna … --u … --p … to generate and send the tar file to the W3C service, it succeeds as expected. ✅
• and when I use bikeshed echidna … --just-tar under GitHub Actions with one particular Bikeshed spec source file, publishing it with the W3C service also succeeds as expected. ✅
• but when I use bikeshed echidna … --just-tar under GitHub Actions in exactly the same way with another particular Bikeshed spec source file instead, publishing it with the W3C service fails unexpectedly. ❌

And troubleshooting it with help from Denis, he says it’s failing in that case because the W3C service is unable to extract the tar file successfully.

FWIW, Denis says the service uses https://github.com/mafintosh/tar-stream to parse/extract tar files — so there may be some bug in that library.

Anyway, I worked around it by switching the GitHub Actions build for the spec(s) to use the system tar command, rather than using bikeshed echidna.

And FWIW https://github.com/WebAssembly/spec/pull/1730 is where this fun has been happening — and the spec that the failure was happening for with bikeshed echidna submission is the WebAssembly JavaScript API spec, the Bikeshed source for which is at https://github.com/WebAssembly/spec/blob/main/document/js-api/index.bs