Test Windows runtime on presubmit, merge build/test runtime jobs.

[ScottTodd]

Progress on #11009, depends on #11048

Changes:

• build_runtime + test_runtime -> build_test_runtime (overhead from repository cloning, artifact upload, and artifact download was taking longer than just running the tests from the same job)
• build_runtime_windows -> build_test_runtime_windows
  • Runs on managed-windows-cpu (larger build machine)
  • Runs tests, instead of just builds (now that all runtime tests pass on Windows)
  • Runs on presubmit now too, instead of just postsubmit (the build appears to be stable)

Sample run: https://github.com/iree-org/iree/actions/runs/3412369869/jobs/5677798847

[GMNGeoffrey]

Maybe make this a single docker run call as in our other build&test workflows

[ScottTodd]

I like having build and test in separate steps, so we get a nice timing breakdown in the action summary:

Duplicating the docker command in each step does repeat many characters though. Can we put our Docker image in uses? https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-a-docker-hub-action Or set a container? https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer

[GMNGeoffrey]

It's not just characters repeating: it's also tearing down and relaunching the container (although I'm not sure how long that takes, in practice. Apparently less than 3s). I've steered away from GitHub actions specific ways of using Docker containers because they're more tied to the CI and therefore harder to reproduce locally or migrate to other CI systems. That includes translating all the docker run options into the GitHub Actions syntax. The script for doing this does additional setup (like creating directories to mount), that would have to be sharded out elsewhere. Overall, it just seems like a false simplification. One option we have would be to start the container running in one step and then use docker exec to run various commands in it.

Regardless, what you've got here is fine for now, though I do still have a slight preference for doing it in a single step to match how other jobs work and avoid launching a container multiple times (although that doesn't seem to have meaningful latency overhead). If you wanted to follow-up by splitting all of them, then that would be fine too :-P

[ScottTodd]

Okay, it's no longer Friday afternoon and I've synced with main. @GMNGeoffrey want to comment on the usage of Docker before I merge? (I also think there's plenty of room for iteration on the Linux and Windows jobs after landing this)

[GMNGeoffrey]

It's not just characters repeating: it's also tearing down and relaunching the container (although I'm not sure how long that takes, in practice. Apparently less than 3s). I've steered away from GitHub actions specific ways of using Docker containers because they're more tied to the CI and therefore harder to reproduce locally or migrate to other CI systems. That includes translating all the docker run options into the GitHub Actions syntax. The script for doing this does additional setup (like creating directories to mount), that would have to be sharded out elsewhere. Overall, it just seems like a false simplification. One option we have would be to start the container running in one step and then use docker exec to run various commands in it.

Regardless, what you've got here is fine for now, though I do still have a slight preference for doing it in a single step to match how other jobs work and avoid launching a container multiple times (although that doesn't seem to have meaningful latency overhead). If you wanted to follow-up by splitting all of them, then that would be fine too :-P