The problem could be that it checks against master and you will probably have changes for R in the ci/ directory. Changes in that directory will trigger a build for the full matrix. So to get the build simple and fast, we should get the ci/ changes for R into master soon.
Uwe On Thu, Sep 6, 2018, at 3:04 PM, Antoine Pitrou wrote: > > Le 06/09/2018 à 15:03, Romain François a écrit : > > I must do something wrong then because it builds them all, all the time > > 🤷♂️. > > Can you show an example? > > > > > > Not a big deal, it’s only about 10 jobs, and i really only care about the r > > job and the only doing the 🐀 analysis. > > > > Commenting out may not be very practical as the plan is to submit small > > pull requests, so it’s almost guaranteed i’ll forget to uncomment about 50% > > of the time. > > > >> Le 6 sept. 2018 à 14:48, Antoine Pitrou <[email protected]> a écrit : > >> > >> > >> Our CI harness will already fast-exit in jobs that are not affected by > >> the current changes (if you change only the R directory, C++ jobs will > >> exit early). > >> > >> If you want it to be even faster, your best bet is to temporarily > >> comment out job entries in .travis.yml. > >> > >> Regards > >> > >> Antoine. > >> > >> > >>> Le 06/09/2018 à 14:26, Romain François a écrit : > >>> Hello, > >>> > >>> Is there a way to have a lighter build matrix on travis, perhaps based on > >>> the branch name, for example when working on the r bindings and not > >>> touching anything else, having only the r job to be triggered would make > >>> it faster for travis. > >>> > >>> For example when working on r features i would typically start the branch > >>> name with « r-» > >>> > >>> Romain > >>> > >
