I’ve read up on monorepos, and it looks like Travis is not really equipped to support monorepos out of the box.
- In monorepos, the amount of rebuilding necessary is determined dynamically by intelligent build tools, and the logic is completely tool-specific.
- So the proposed feature is not an adequate solution. It may be good enough specifically for the OP in the specific situation, but I foresee requests for all sorts of additional logic flooding in quickly if this is implemented.
An adequate solution would either be
- provide beefier build machines with more cores (to commercial users on demand) that can run many tasks in parallel and build everything within a single job; or
- introduce a “planning” stage that would be able to edit
.travis.yml(or, more probably, its representation) on the fly, e.g. disabling jobs as necessary; or - in conjunction with the flowchart build model, ability to edit config of the jobs down the flowchart edges from the current job
- to avoid conflicts, there should probably be a phase for this only during which the configs are accessible and are protected with a critical section synchronization primitive
A workaround would be to
- Have a series of stages with the same configuration which would
- determine what to build according to the specific tool’s logic
- build what is possible within the time limit
- pass information to the next stage so that it can do the same, picking off from where this job stopped
- of course, you can run several such jobs in parallel, too, but it’s going to be tricky due to inability to pass information between sibling jobs