GeezerVison

Thank you!!
It looks like that test took about 5 minutes to run. My only question is whether we want that on every push or if we want to just give maintainers the option to run them manually.
Either way, this is fantastic to have and I look forward to some version of it landing soon!

Yeah, the reason for being slow is that it downloads a full VM image, extract it and boots it up before doing anything. I think 5 minutes are bearable, though

I wonder if there's a clever way to make it somehow depend on the cross-compilation target so that if it wouldn't build we won't waste time spinning up the VM for testing... EDIT: Or really just any/all of the compilation targets. If any compilation target is broken, that's reason enough to skip the expensive VM test.

Perhaps:

needs: build

Reference https://stackoverflow.com/questions/58457140/dependencies-between-workflows-on-github-actions

Well, if we do needs: build, it will run sequentially instead of in parallel...

The builds are very fast. I see the argument on the other side though.

That the VM build starts later? Maybe more waiting

How can we get builds to run on external pull requests like this?

We don't have any secrets to worry about leaking.

How can we get builds to run on external pull requests like this?

We don't have any secrets to worry about leaking.

😄 #415 should do it. Alternately we could favor pull_request over push though I do still prefer both.
EDIT: We could/should also update the builds job accordingly whichever way we go.

Given @nathany's approval I think we should merge this. If the build times become onerous we can revisit moving them out to the forthcoming slow-tests that I'm planning for illumos. Better to err on the side of testing.