[Vm-dev] appveyor queue is too long

[Ben Coman]

On Thu, 3 Jan 2019 at 21:58, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
>
>
> 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...
>>>
>>
You could maybe have another travis account, much like I recently set one
up for myself...
https://travis-ci.org/bencoman/opensmalltalk-vm/builds

I've tried searching for whether Travis would have a problem with that and
not been able to find anything.


>
>> 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
>

Sounds okay, but before you run with that, just another idea to consider...

I see the main issue is the delay when trying to iterate on a PR.
So perhaps the way forward is that PRs only the eight "main" platforms,
providing a 10 minute iteration.
When you are done, after the PR is merged, a long build is not a problem,
so a full build of the Cog branch would be okay.

It seems this could be configured using conditional stages...
    https://docs.travis-ci.com/user/conditional-builds-stages-jobs/

Also it seems any incoming PR-build could auto cancel the Cog-branch
full-build,
thus ensure that doesn't get in the way of fast PR iterations.
    https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation

A side benefit might be encouraging discipline in submitting all changes
via PR.
Even if the developer creating the PR immediately merges it themselves, a
PR provides nice mechanism to group related commits,
and also provides a nice place to hang comments, even after merging.
No need anyone current committing directly to Cog to wait for those
comments.

cheers -ben


>
>>> 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/a9dae888/attachment.html>