On Tue, Feb 13, 2018 at 05:01:35PM +0000, Rui Carmo wrote: > > A full build environment (the way I’m used to having it) comprises the > end-to-end automation for creating a full build,
A full build of what? It's one command to rebuild the whole OS. Is that the goal? > triggered by an external code repository This pretty significantly reduces the scope of the problem, since only a couple of the forks use version control. This simplifies the task somewhat, at least. > and (when possible) doing automated testing. I think this is probably the most useful part of what you describe. Do you intend to write the tests? > I understand that you might be used to manually bootstrap things, Please don't start making assumptions. I'm just trying to clarify what you're after. >but I tend to go for fully reproducible builds and that usually requires a >minimal degree of automation. I did that for my Inferno builds for the Pi >(which, alas, are now lost) and do rely on Linux tools for building, because >that’s what I can host in the public cloud (which is also what I do for work). Plenty of us run Plan 9 on public cloud providers. There's even been some success on running it with crippled providers like AWS and GCE. Obviously, the task is easier when you use providers that offer full KVM services. We've had virtio drivers for a while, and it makes the job much easier. > Fortunately, I have access to machines with nested virtualisation, so I might > be able to get Plan9 running inside QEMU inside a modern Linux kernel with > fair performance - but that does not preclude the need to automate things. I'm still trying to understand why you'd even need nested virtualization. khm
