[Vm-dev] appveyor queue is too long

[Nicolas Cellier]

Le jeu. 3 janv. 2019 à 15:26, Ben Coman <btc at openinworld.com> a écrit :

>
>
>
> 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
>
>
side note: another grief is that PR which are just fast-forward merge
triggers 2 builds...
I did not inquire if there was a solution for that.


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