But if you decide whether a job needs to run in a “job manager” job, you don’t really need to pull Nx in each job to be able to cancel it. You only need to send that job some signal – e.g. by placing a flag into workspace contents.
Without Run a chunk of user code before the stock installation logic, this probably means that you cannot use much of Travis’ stock logic (restore package cache, install custom software) and will have to do the same stuff manually.
The other “natural way” I suggested in How to skip jobs based on the files changed in a subdirectory? - #15 by native-api is to use “beefier build machines” that would be able to run lots of tasks in parallel. Note that whenever you split a build into jobs by hand, you’re taking a tax of an artificial barrier (not unlike nested makefiles) and having to set up the environment in every job.
Unless Travis can provide you with those on demand (they never commented either way), you’ll need to purchase Travis Enterprise which would allow you to build on your own worker machines of however much power you need. If you need to run 50 jobs in parallel every build and lots and lots of builds per day, you seem to be a large-scale enough consumer for that.