[Vm-dev] appveyor queue is too long

[Nicolas Cellier]

Le jeu. 3 janv. 2019 à 13:23, Fabio Niephaus <lists at fniephaus.com> a écrit :

>
>
>
> On Thu, Jan 3, 2019 at 12:31 PM Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>> All this take really a long time. Are the stack build really necessary?
>> We could build one for 32bits and one for 64bits, just to verify that we
>> did not break the spurstacksrc and spurstack64src, but only if we changes
>> spurstacksrc, spurstack64src or eventually platforms support code (if ever
>> spurstacksrc was using different support code than spursrc, which I doubt).
>> Is it possible to trigger the build on specific changes?
>> I wonder if we could not arrange to have another subproject that would
>> build those alternative VM...
>>
>
> Another idea: set up an orphan branch with CI builds that pull the Cog
> branch and build the stack VMs. Then, we could set up Travis to build this
> specific branch once a week/month and remove these builds from our main
> config. In the worst case, we would notice a broken stack VM after a
> week/month which might be tolerable.
>
>
+1


>> Le mer. 2 janv. 2019 à 17:13, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> a écrit :
>>
>>> Reminder: we also have [skip travis] and [skip appveyor] when we only
>>> change platforms specific files, or build instructions.
>>>
>>> Le mer. 2 janv. 2019 à 16:15, Fabio Niephaus <lists at fniephaus.com> a
>>> écrit :
>>>
>>>>
>>>>
>>>>
>>>> On Wed, 2 Jan 2019 at 3:46 pm, Nicolas Cellier <
>>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>>
>>>>>
>>>>> Or maybe we don't interrupt jobs that already started?
>>>>>
>>>>
>>>> I think you are right. If that's not the case, we should fix it. Also,
>>>> we should use [ci skip] more often (but carefully of course).
>>>>
>>>>
>>>>>
>>>>> Le mer. 2 janv. 2019 à 15:44, Nicolas Cellier <
>>>>> nicolas.cellier.aka.nice at gmail.com> a écrit :
>>>>>
>>>>>> Hi all,
>>>>>> didn't we configure appveyor to cancel the builds when a newer commit
>>>>>> is performed in the same branch/PR?
>>>>>>
>>>>>> Currently, job queue is too deep (and slow)
>>>>>> https://ci.appveyor.com/project/OpenSmalltalk/vm/history
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190103/1ef70a1c/attachment-0001.html>