sideshowbarker
commented
7 months ago But the bigger savings would probably come from making changes to the
workflows/ci-spec.ymlfile, to factor out the installing-the-prerequisite-software steps —Checkout repo,Setup Node.js,Setup Bikeshed, andSetup Sphinx—steps into their ownprepjob. And then we make thebuild-core-spec,build-js-api-spec,build-web-api-spec, andpublish-to-w3c-TRjobs all require/depend on thatprepjob, so that it runs first, just once.
OK, I tried that in https://github.com/WebAssembly/spec/pull/1730/commits/ddb1751eab662de0e555a9a97e3ead6b4f28cdaa but quickly discovered it doesn’t work — and won’t work. And for the record here, the reason is: each job runs on a different, new machine/runner. So there’s no way to preserve shared state/environment among jobs.
Apparently this is a fundamental characteristic of GitHub Actions that people generally know or are expected to know…
rossberg
Short answer:
Longer answer
> To reduce turnaround time and save resources, wouldn't it be better to move the new build steps to the existing build targets, so that it reuses their work? So the problem there is: Bikeshed needs to be run twice on each of the specs anyway — at least if we want the https://webassembly.github.io/spec/ Bikeshed versions to retain the “Editor’s Draft” formatting they have now, rather than instead having the formatting of those change to being the same “Working Draft” formatting that the https://www.w3.org/TR versions have. If the editors and the groups chairs are were OK with instead changing the https://webassembly.github.io/spec/ versions to have the same “Working Draft” formatting that the https://www.w3.org/TR/ versions have, then we’d need to run Bikeshed only once on each spec. I’d personally be fine with the https://webassembly.github.io/spec/ versions having the “Working Draft” formatting — and as far as I’m aware, W3C policy doesn’t explicitly prohibit us from doing so. That said, I think that in general, W3C management would prefer that the “Working Draft” formatting only be used for the versions published at https://www.w3.org/TR/ URLs. But I think we could still try it if we wanted to, and see if anybody notices and asks us to stop doing it (in which case, we’d just flip it back). But otherwise, to retain the “Editor’s Draft” formatting of the https://webassembly.github.io/spec/ versions means that we have to first run `bikeshed` once as it’s already being run — with `Status: ED` set in the `.bs` sources for each spec — and then to get the “Working Draft” formatting for the https://www.w3.org/TR/ versions, we need to run `bikeshed` again, but with the `Status` property instead set to `WD`. > My only concern is that the new publish-to-w3c action redoes everything from scratch. Installing the prerequisite software and doing the Sphinx build already takes significant time on CI. As far as the time requirements, one thing to note is: the `publish-to-w3c-TR` CI job this PR adds is run in parallel with the existing CI jobs that do the builds and publishing for the existing https://webassembly.github.io/spec/ versions. And from watching all the jobs run for this PR branch, I can see that `publish-to-w3c-TR` job finishes are almost exactly the same time — roughly 6 minutes and 30 seconds — as the `build-core-spec`+`publish-spec` combination. In other words, the existing CI takes about 6.5 minutes to complete, and the patch in this PR doesn’t increase that. All that said, as far as resource usage, it’s true that the current patch in this PR as currently written does basically doubles the resource usage — and I guess there are few changes that could be made to decrease that. As far as exactly what changes could be made: The opportunities to make changes to the makefiles to reduce the resource usage of the build itself are very few — because: - to get W3C autopublishing working, we’ll currently need to run `bikeshed` twice for each spec, regardless - the `bikeshed` target in the `core/Makefile` is what consumes most of the time and resources, and we must run it twice However, I guess we could factor the Sphinx part of that `bikeshed` target into its own target — in which case, we could make the build run that part just once, only before the first time we run the Bikeshed part — and not re-run it a second time. That’d probably cut 30 seconds out of the 6 minutes and 30 seconds the `publish-to-w3c-TR` job takes. So I’ll try it. But the bigger savings would probably come from making changes to the `workflows/ci-spec.yml` file, to factor out the installing-the-prerequisite-software steps — `Checkout repo`, `Setup Node.js`, `Setup Bikeshed`, and `Setup Sphinx` —steps into their own `prep` job. And then we make the `build-core-spec`, `build-js-api-spec`, `build-web-api-spec`, and `publish-to-w3c-TR` jobs all require/depend on that `prep` job, so that it runs first, just once. So I’ll try that first — both because it’s quicker and easier to try then refactoring the `bikeshed` makefile target is, and also because it should give a more-significant reduction in the overall resource usage (though not in the overall build time).