For projects that share one CI machine
Running
Man.
If several of your projects run their CI on the same computer, two pushes at the same time can overload it. Builds then slow down or fail even though nothing is wrong with the code. Running Man sits between your CI and the machine. It starts a job only when enough CPU and memory are free for it, and holds the rest until there is. If the same tests have already run on the same code, it reuses the earlier result.
Adding runners doesn't help.
Another runner on the same machine is just another job competing for the same CPU and memory. The simulation below shows how Running Man schedules jobs from two projects on one machine.
Testing several pull requests together.
Running Man can also combine the pull requests that are ready to merge onto a temporary branch and run CI on that branch. If the run passes, they all pass. When the run fails the group is split in half and each half is tested. It keeps splitting until it has found the pull request that caused the failure. It never merges anything and never changes your branches.
- Batch#101#102#103#104#105Five pull requests are ready. They go onto a temporary branch.
- RunCI failsCI runs on the branch and fails.
- Split#101#102#103#104#105The two halves are tested separately. The first half passes.
- Result#101#102#103#105#104#104 caused the failure. The other four pass.
The code is not public yet. It will be released under the MIT license.
Running Man is written in Rust. The scheduler runs as a service, and running-man git batch tests pull requests together. Scheduling decisions are recorded in a SQLite database, so you can check later why a job ran when it did.
Not released yet.
The repository opens with the first release.