ID: | 4580 |
From: | rn...@igor2.repo.hu |
Date: | Sat, 28 Nov 2020 13:39:19 +0100 (CET) |
Subject: | [pcb-rnd] compile/test farm - poll on potential participation |
replies: | 4582 from John Griessen <jo...@cibolo.com> , 4592 from Nicklas SB Karlsson <nk...@nksb.online> , 4603 from rn...@igor2.repo.hu , 4612 from rn...@igor2.repo.hu |
Hi all, from time to time we have bugs detected only after a release. If we did more testing before release, we could avoid that. One of the cases where we could improve a lot is the non-x86_64 and/or non-linux targets: most of our users are on x86_64, so that platform gets a lot of testing, but anything beyond that, even i386, suffers from lack of testing. We have an auto-build system ("Continous Integration", "Continous Testing", if you like buzzwords), and it catches a lot of bugs very early. We could just run more of those (more operating systems, more architectures). Currently the bottleneck is that I simply do not have the resources to do so: computer power + electricity. And that's where you could potentially help. At the moment we have an x86_64 compile-every-commit (CEC) host donated by a Hungarian hacker, plus I plan to set up an i386 CEC on repo.hu. We could extend that with more CEC and more ST (scheduled-time) and maybe even MS (manually-started) tests. If you participate, you provide some disk space, some RAM, some CPU time so that an automatic system can do test compilation. Beyond the one-time setup, you generally don't need to do anything, just let it run, all triggers and tests are fully automatic. I plan to have three different setups: 1. CEC (compile-every-commit) These are the most needy setups. They must run 24/7. They connect to our IRC network and are triggered by commit messages there. Since we assume they are fast in compiling, we need only one per arch+OS combo. This setup is fully automatic. It's best choice if you have a 24/7 server with spare resources. 2. ST (scheduled-time) Some people run systems that have heavy load for most of the day but a few hours time slot can be identified when the load drops, yet the server needs to keep running. I plan to code a variant that could be configured to run within a specific time frame (e.g. every night between 1:00 and 3:00). It wouldn't try to compile every single commit, and wouldn't always need to utilize the entire time slot. It would contact repo.hu and check out a pending task then report back when compilation/testing finished. If there's more time in the local slot, it'd repeat. 3. MS (Manually started) This needs the least effort from the participant: you need to install qemu, download an OS image I provide, and whenever you know you won't use your computer for an hour, run a shell script (or bat) that starts qemu. There would be preinstalled software _within_ the OS image that does the same pending task checkout as the ST script. Then it would use its screen to tell you about the progress. You can turn it off any time by simply closing the window (but if you turn it off before it finishes, the session is lost, and the CPU time spent is wasted). This is useful if you don't have a server but a strong desktop machine or laptop that has idle time; time when you don't do anything CPU internsive but still you don't turn the computer off. E.g. during a lunch break, or while you are wathing a movie. About the tests performed: I plan to provide options for participants to select what kind of tests they want to spend their resources on: pcb-rnd only, any ringdove and related projects (e.g. dependencies), or any free software hosted on repo.hu. Please let me know if you are interested in participating in CEC, ST or MS, so I know which variants I should develop. Best regards, Igor2
Reply subtree:
4580 [pcb-rnd] compile/test farm - poll on potential participation from rn...@igor2.repo.hu
4582 Re: [pcb-rnd] compile/test farm - poll on potential participation from John Griessen <jo...@cibolo.com>
4590 Re: [pcb-rnd] compile/test farm - poll on potential participation from rn...@igor2.repo.hu
4591 Re: [pcb-rnd] compile/test farm - poll on potential participation from TQ Hirsch <th...@thequux.com>
4595 Re: [pcb-rnd] compile/test farm - poll on potential participation from ka...@aspodata.se
4596 Re: [pcb-rnd] compile/test farm - poll on potential participation from TQ Hirsch <th...@thequux.com>
4597 Re: [pcb-rnd] compile/test farm - poll on potential participation from Evan Foss <ev...@gmail.com>
4598 Re: [pcb-rnd] compile/test farm - poll on potential participation from Dave McGuire <mc...@neurotica.com>
4599 Re: [pcb-rnd] compile/test farm - poll on potential participation from ka...@aspodata.se
4598 Re: [pcb-rnd] compile/test farm - poll on potential participation from Dave McGuire <mc...@neurotica.com>
4599 Re: [pcb-rnd] compile/test farm - poll on potential participation from ka...@aspodata.se
4598 Re: [pcb-rnd] compile/test farm - poll on potential participation from Dave McGuire <mc...@neurotica.com>
4599 Re: [pcb-rnd] compile/test farm - poll on potential participation from ka...@aspodata.se
4598 Re: [pcb-rnd] compile/test farm - poll on potential participation from Dave McGuire <mc...@neurotica.com>
4599 Re: [pcb-rnd] compile/test farm - poll on potential participation from ka...@aspodata.se
4603 [pcb-rnd] compile/test farm: basic documentation from rn...@igor2.repo.hu
4612 Re: [pcb-rnd] compile/test farm - update + plans from rn...@igor2.repo.hu