Migrate to GitHub Actions

[foolip]

An umbrella issue for migrating from Travis CI to GitHub Actions. Repositories would be affected (current have a .travis.yml file):

Living Standards

• compat
• console
• dom
• encoding
• fetch
• fullscreen
• html
• infra
• mimesniff
• notifications
• quirks
• storage
• streams
• url
• xhr

Others

• books
• figures
• html-build
• html-differences (archived)
• misc-server
• participate.whatwg.org
• platform.html5.org
• sg
• wattsi
• whatwg.org

[annevk]

Given that the secrets would become centralized I think we could also move the configuration file for standards to https://github.com/whatwg/spec-factory.

[foolip]

whatwg/whatwg.org#322 is what's needed for deploy.sh, and whatwg/fullscreen#173 is trying it with Fullscreen.

@annevk a bunch of specs have customized build steps and so will differ somewhat, is that OK or will intentional differences have to be annoying every time factory.py is run?

[annevk]

We could encode intentional differences in factory.json as we have done for other such things. That might be nice to keep the knowledge of such things centralized, but I can also see that as being an argument for not trying to adopt spec-factory for it now.

[foolip]

https://github.com/whatwg/encoding/blob/master/Makefile is an example of this. How is that currently managed?

[annevk]

That's a somewhat special case. The templated bit is @@bs@@ which occurs several times in https://github.com/whatwg/spec-factory/blob/master/Makefile.template. https://github.com/whatwg/spec-factory/blob/master/factory.py#L56 fills in that variable by looking at the filename of the only .bs file in the repository.

(We could replace this with using factory.json if we want I suppose. That didn't exist at first.)

[domenic]

I'm a bit confused by the last few comments. The Makefile in encoding is already generated by spec-factory, using https://github.com/whatwg/spec-factory/blob/202daf74a12c784a58c7184378bd16cf92dc3963/factory.json#L9-L11 .

I think @annevk was suggesting generating the .travis.yml counterpart in spec-factory. The variance there is:

• ENCRYPTION_LABEL is different in each spec
• Some specs require different dependencies, e.g. Encoding requires Python, Streams requires Node.js and does some stuff with the reference implementation.

[foolip]

My bad, I'd looked at https://github.com/whatwg/spec-factory during the day and thought I didn't see Makefile in there, but it's there.

I don't think it'll be hard to arrange for python and node to be installed. Doing so is actually very fast on GitHub Actions since they're already on disk and only the PATH is updated. Would there be any harm in always enabling specific versions of python and node?

[foolip]

(Note that some version of python and node will be present if we do nothing as well, a bunch of common software is installed in these agents by default.)

[domenic]

If that's the case then I'd be happy to just enable them everywhere.

Streams is pretty aggressive about using recent JS features so I'd like to get it on a recent Node, not the default.

[foolip]

As I was going to merge whatwg/compat#126 as the first conversion, I was going to change the branch protection rules and saw this:

Since it will be a pain to change later, I want to ask if anyone has opinions about the name of the check here. Note that in the integration with the Checks API, GitHub Actions uses the workflow name as the Check Suite name, and the job name as the name of the individual check.

I can never come up with a good name for the workflow, so I usually call it the same thing as the job, leading to silly things like "build / build". But the branch protection rules care only about the check name, not the check suite name.

So, does anyone care what the name of the workflow (check suite) and job (check) is? Specifically, should it be "Build"?

[domenic]

I don't fully understand the distinction they're trying to make between workflow and job.

Naming is hard here since our script serves dual purpose: on PRs it's something like "build", whereas on master it's "build and deploy". Given that, I don't have any good ideas. "Build (and maybe deploy)" is kind of silly, so maybe just "Build" is the way to go.

[foolip]

I'll go with a capitalized "Build" as both the workstream and job name.

[foolip]

A bunch of changes in https://github.com/whatwg/spec-factory should make this pretty easy to roll out for most specs now. I'll start with compat.

[foolip]

whatwg/compat#126 worked and https://compat.spec.whatwg.org/ is updated as a result. Everything look good, but I won't do any more right now in case there's a problem. I'll pick this up next week.

[foolip]

I'm going on vacation for two weeks and won't have time to finish this before then. Nothings going to break, but the remaining work is html and html-build. Here are the WIP branches I have:
https://github.com/whatwg/html/commits/github-actions
https://github.com/whatwg/html-build/commits/github-actions

It seems tricky (to me) to migrate these one at a time, since html uses html-build, and html-build uses html to test itself.

Where I got stuck when I looked at this is that how the Docker image is updated after a successful build for caching purposes. I think keeping all of that as-is (directly invoking docker) would work, but migrating it do GitHub Action's native support for running steps in Docker seems trickier.

If anyone would like to pick this up, that would be great, otherwise I'll eventually get to it.

[domenic]

Here is my plan for html + html-build:

• Simplify the HTML build Docker business: Improvements to the CI Docker build html-build#252

• Try to move to a model where html-build's CI section is more like Wattsi: it produces a Docker image which you can docker run given a checked-out copy of whatwg/html as input, and a writable output directory where it puts the results.

  • The CI for html-build then takes care of building this image and deploying to Docker Hub
  • It performs tests by checking out whatwg/html and doing docker run and seeing if anything breaks
  • This change will require changes to whatwg/html: instead of checking out html-build as a Git repository and running a single bash script, it will download html-build from Docker Hub and do the ssh + rsync steps itself. I'll put those in the .travis.yml for now.

• Now that html and html-build are decoupled a good bit, move html-build to GitHub Actions.

• Move html to GitHub Actions.

An added bonus of this is that it will end up producing a Docker image that does the whole end-to-end build process. That could be used to replace wattsi-server with html-build-server, perhaps. Or give people who want to do entire end-to-end builds a single docker command that requires no dependencies. There might be some additional work needed there to make this pleasant, as the CI does a lot of work around validation and PDF generation that we might not want for those use cases, but it's a start.

[foolip]

Sounds like a plan, thanks @domenic!