You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@arrow.apache.org by Antoine Pitrou <an...@python.org> on 2018/09/06 12:48:54 UTC
Re: Lighter build matrix on a language specific fork.
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
>
Re: Lighter build matrix on a language specific fork.
Posted by Wes McKinney <we...@gmail.com>.
The rpath issue does not need to be resolved right now, though. I will
review the patch again and merge if all looks good
On Fri, Sep 7, 2018 at 4:53 AM Kouhei Sutou <ko...@clear-code.com> wrote:
> Hi,
>
> We can get Arrow's library directory by
> "pkg-config --variable=libdir arrow". Does this help this case?
>
> Thanks,
> --
> kou
>
> In <47...@purrple.cat>
> "Re: Lighter build matrix on a language specific fork. " on Fri, 7 Sep
> 2018 10:47:03 +0200,
> Romain Francois <ro...@purrple.cat> wrote:
>
> > Addressed most of the comments. Anyone knows how to set rpath
> dynamically in:
> > https://github.com/apache/arrow/pull/2489#discussion_r215875597 <
> https://github.com/apache/arrow/pull/2489#discussion_r215875597>
> >
> > Maybe pkg-config can help ?
> >
> >> Le 7 sept. 2018 à 00:40, Wes McKinney <we...@gmail.com> a écrit :
> >>
> >> OK, if you could address the comments that I left, after that I can
> merge
> >> the PR
> >>
> >> On Thu, Sep 6, 2018 at 8:39 AM Romain François <ro...@purrple.cat>
> wrote:
> >>
> >>> As far as I’m concerned the initial pr is good to go, the intent is to
> >>> just have an r package that builds against the C++ library and that
> checks
> >>> on travis.
> >>>
> >>> Actual code that does stuff will follow. (I have two branches on top
> of it
> >>> for later).
> >>>
> >>> But this is bare minimal by design.
> >>>
> >>> Romain
> >>>
> >>>> Le 7 sept. 2018 à 00:06, Wes McKinney <we...@gmail.com> a écrit :
> >>>>
> >>>> Yes, as soon as the initial R PR is in (and the CI scripts aren't
> >>> changing)
> >>>> the build will be faster.
> >>>>
> >>>> @Romain how much more work do you want to do on the initial PR? We can
> >>>> review and merge by end of week if that sounds good
> >>>>
> >>>>> On Thu, Sep 6, 2018 at 6:10 AM Uwe L. Korn <uw...@xhochy.com> wrote:
> >>>>>
> >>>>> 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 <an...@python.org> 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
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>>
> >
>
Re: Lighter build matrix on a language specific fork.
Posted by Kouhei Sutou <ko...@clear-code.com>.
Hi,
We can get Arrow's library directory by
"pkg-config --variable=libdir arrow". Does this help this case?
Thanks,
--
kou
In <47...@purrple.cat>
"Re: Lighter build matrix on a language specific fork. " on Fri, 7 Sep 2018 10:47:03 +0200,
Romain Francois <ro...@purrple.cat> wrote:
> Addressed most of the comments. Anyone knows how to set rpath dynamically in:
> https://github.com/apache/arrow/pull/2489#discussion_r215875597 <https://github.com/apache/arrow/pull/2489#discussion_r215875597>
>
> Maybe pkg-config can help ?
>
>> Le 7 sept. 2018 à 00:40, Wes McKinney <we...@gmail.com> a écrit :
>>
>> OK, if you could address the comments that I left, after that I can merge
>> the PR
>>
>> On Thu, Sep 6, 2018 at 8:39 AM Romain François <ro...@purrple.cat> wrote:
>>
>>> As far as I’m concerned the initial pr is good to go, the intent is to
>>> just have an r package that builds against the C++ library and that checks
>>> on travis.
>>>
>>> Actual code that does stuff will follow. (I have two branches on top of it
>>> for later).
>>>
>>> But this is bare minimal by design.
>>>
>>> Romain
>>>
>>>> Le 7 sept. 2018 à 00:06, Wes McKinney <we...@gmail.com> a écrit :
>>>>
>>>> Yes, as soon as the initial R PR is in (and the CI scripts aren't
>>> changing)
>>>> the build will be faster.
>>>>
>>>> @Romain how much more work do you want to do on the initial PR? We can
>>>> review and merge by end of week if that sounds good
>>>>
>>>>> On Thu, Sep 6, 2018 at 6:10 AM Uwe L. Korn <uw...@xhochy.com> wrote:
>>>>>
>>>>> 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 <an...@python.org> 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
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>
Re: Lighter build matrix on a language specific fork.
Posted by Romain Francois <ro...@purrple.cat>.
Addressed most of the comments. Anyone knows how to set rpath dynamically in:
https://github.com/apache/arrow/pull/2489#discussion_r215875597 <https://github.com/apache/arrow/pull/2489#discussion_r215875597>
Maybe pkg-config can help ?
> Le 7 sept. 2018 à 00:40, Wes McKinney <we...@gmail.com> a écrit :
>
> OK, if you could address the comments that I left, after that I can merge
> the PR
>
> On Thu, Sep 6, 2018 at 8:39 AM Romain François <ro...@purrple.cat> wrote:
>
>> As far as I’m concerned the initial pr is good to go, the intent is to
>> just have an r package that builds against the C++ library and that checks
>> on travis.
>>
>> Actual code that does stuff will follow. (I have two branches on top of it
>> for later).
>>
>> But this is bare minimal by design.
>>
>> Romain
>>
>>> Le 7 sept. 2018 à 00:06, Wes McKinney <we...@gmail.com> a écrit :
>>>
>>> Yes, as soon as the initial R PR is in (and the CI scripts aren't
>> changing)
>>> the build will be faster.
>>>
>>> @Romain how much more work do you want to do on the initial PR? We can
>>> review and merge by end of week if that sounds good
>>>
>>>> On Thu, Sep 6, 2018 at 6:10 AM Uwe L. Korn <uw...@xhochy.com> wrote:
>>>>
>>>> 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 <an...@python.org> 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
>>>>>>>>
>>>>>>
>>>>
>>
>>
Re: Lighter build matrix on a language specific fork.
Posted by Romain François <ro...@purrple.cat>.
Thanks. I will do that first thing in the morning.
I just skimmed through them and it’s nothing dramatic, mostly oversights. I just can’t act on them right now, #parenting 👨👧
> Le 7 sept. 2018 à 00:40, Wes McKinney <we...@gmail.com> a écrit :
>
> OK, if you could address the comments that I left, after that I can merge
> the PR
>
>> On Thu, Sep 6, 2018 at 8:39 AM Romain François <ro...@purrple.cat> wrote:
>>
>> As far as I’m concerned the initial pr is good to go, the intent is to
>> just have an r package that builds against the C++ library and that checks
>> on travis.
>>
>> Actual code that does stuff will follow. (I have two branches on top of it
>> for later).
>>
>> But this is bare minimal by design.
>>
>> Romain
>>
>>> Le 7 sept. 2018 à 00:06, Wes McKinney <we...@gmail.com> a écrit :
>>>
>>> Yes, as soon as the initial R PR is in (and the CI scripts aren't
>> changing)
>>> the build will be faster.
>>>
>>> @Romain how much more work do you want to do on the initial PR? We can
>>> review and merge by end of week if that sounds good
>>>
>>>> On Thu, Sep 6, 2018 at 6:10 AM Uwe L. Korn <uw...@xhochy.com> wrote:
>>>>
>>>> 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 <an...@python.org> 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
>>>>>>>>
>>>>>>
>>>>
>>
>>
Re: Lighter build matrix on a language specific fork.
Posted by Wes McKinney <we...@gmail.com>.
OK, if you could address the comments that I left, after that I can merge
the PR
On Thu, Sep 6, 2018 at 8:39 AM Romain François <ro...@purrple.cat> wrote:
> As far as I’m concerned the initial pr is good to go, the intent is to
> just have an r package that builds against the C++ library and that checks
> on travis.
>
> Actual code that does stuff will follow. (I have two branches on top of it
> for later).
>
> But this is bare minimal by design.
>
> Romain
>
> > Le 7 sept. 2018 à 00:06, Wes McKinney <we...@gmail.com> a écrit :
> >
> > Yes, as soon as the initial R PR is in (and the CI scripts aren't
> changing)
> > the build will be faster.
> >
> > @Romain how much more work do you want to do on the initial PR? We can
> > review and merge by end of week if that sounds good
> >
> >> On Thu, Sep 6, 2018 at 6:10 AM Uwe L. Korn <uw...@xhochy.com> wrote:
> >>
> >> 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 <an...@python.org> 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
> >>>>>>
> >>>>
> >>
>
>
Re: Lighter build matrix on a language specific fork.
Posted by Romain François <ro...@purrple.cat>.
As far as I’m concerned the initial pr is good to go, the intent is to just have an r package that builds against the C++ library and that checks on travis.
Actual code that does stuff will follow. (I have two branches on top of it for later).
But this is bare minimal by design.
Romain
> Le 7 sept. 2018 à 00:06, Wes McKinney <we...@gmail.com> a écrit :
>
> Yes, as soon as the initial R PR is in (and the CI scripts aren't changing)
> the build will be faster.
>
> @Romain how much more work do you want to do on the initial PR? We can
> review and merge by end of week if that sounds good
>
>> On Thu, Sep 6, 2018 at 6:10 AM Uwe L. Korn <uw...@xhochy.com> wrote:
>>
>> 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 <an...@python.org> 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
>>>>>>
>>>>
>>
Re: Lighter build matrix on a language specific fork.
Posted by Wes McKinney <we...@gmail.com>.
Yes, as soon as the initial R PR is in (and the CI scripts aren't changing)
the build will be faster.
@Romain how much more work do you want to do on the initial PR? We can
review and merge by end of week if that sounds good
On Thu, Sep 6, 2018 at 6:10 AM Uwe L. Korn <uw...@xhochy.com> wrote:
> 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 <an...@python.org> 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
> > >>>
> > >
>
Re: Lighter build matrix on a language specific fork.
Posted by "Uwe L. Korn" <uw...@xhochy.com>.
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 <an...@python.org> 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
> >>>
> >
Re: Lighter build matrix on a language specific fork.
Posted by Antoine Pitrou <an...@python.org>.
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 <an...@python.org> 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
>>>
>
Re: Lighter build matrix on a language specific fork.
Posted by Romain François <ro...@purrple.cat>.
I must do something wrong then because it builds them all, all the time 🤷♂️.
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 <an...@python.org> 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
>>