Mailing list archives : pcb-rnd

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