mps
mps copied to clipboard
Ravenbrook
Development virtual machine setup procedures.
It may well be worth doing a quick Dockerfile that can build and run the tests for MPS with Ubuntu and whatever else, as well as gcc, clang, etc.
That won't help for macOS, Windows build environments, but it would provide an easy source of truth for a Linux build environment and one that is a bit easier than lxd and friends. (Depending on the set up, it can also work for testing under qemu for more CPU architectures like doing arm64 on x86_64 host.)
I can do this as I've done similar things before.
It may well be worth doing a quick
Dockerfile...
One of the things I'm not clear about is whether we can be sure that tests run inside containers, on VMs, on QEMU, etc. represent our target platforms. In other words, how much confidence do they give us? Increasingly, our target platforms are virtual, of course, but I think this needs some analysis.
Our CI builds are definitely running in VMs of various sorts.
For our main commercial client we are doing manual testing on a machine built to their spec, but we can't afford to do that for all our supported platforms. In fact, it's come up recently that we should define what "supported" means for the public MPS on GitHub, since it's quite different from Ravenbrook's commercial "support", which involves a contract. The word gets bandied around a lot as meaning "someone vaguely intends for this software to work in a context".
#145 also relevant, since Cirrus CI seems to be mostly layered on Docker.
#145 also relevant, since Cirrus CI seems to be mostly layered on Docker.
See "is this really LI?" in https://github.com/Ravenbrook/mps/blob/0442b6089ddd0aa33d5bb0de3f620a958d4b33c6/.cirrus.yml#L82-L92
One of the things I'm not clear about is whether we can be sure that tests run inside containers, on VMs, on QEMU, etc. represent our target platforms.
This is a good point. There are subtle differences.
For our main commercial client we are doing manual testing on a machine built to their spec, but we can't afford to do that for all our supported platforms.
You have my sympathy. Ambitious open source projects are chronically underserved by the infrastructure market. The free offerings fall just short of adequate, and the cheapest paid ones are just a bit too pricey. I have observed this phenomenon for years, so it's probably intrinsic in the cost structure of the business.
The best medium-to-long-term approach may be to pool resources with like-minded projects, e.g. rent shared servers to bring down the cost per project. Most servers sit idle most of the time so this ought to be good enough for open source. We have a long-standing TODO to bring up CI under Scheme.org, but it's expensive to do exotic (non-amd64, non-linux) platforms.
Our CI builds are definitely running in VMs of various sorts.
Cirrus CI seems to be mostly layered on Docker.
All of them are probably using Docker or similar containers. Bare metal CI is difficult to provide since the provider has to clean up the server after each job so the next client gets a clean slate. Without containers, that probably involves a memory-backed file system and a reboot to clear it.
