[Vm-dev] the purpose of CI

[Fabio Niephaus]

+1 for using more (feature) branches for OSVM development

Also, there's no need to temporarily remove a build. We can flag builds as
"allow to fail" [1].


[1]
https://docs.travis-ci.com/user/customizing-the-build#Rows-that-are-Allowed-to-Fail

-- 

On Sun, May 28, 2017 at 4:20 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

>
> +1
>
> Exactly what I named continuous desintegration in recent post
>
> http://forum.world.st/OpenSmalltalk-opensmalltalk-vm-24bea9-Fix-compilation-of-SoundPlugin-on-Windows-td4947979.html
>
>
>
> 2017-05-28 15:46 GMT+02:00 Ben Coman <btc at openinworld.com>:
>
>>
>>
>> Maybe I'm speaking out of turn from the sidelines, but just curious to
>> ask a leading question...
>>
>> What is the purpose of the Continuous Integration system?
>>
>>
>>
>> I notice Travis has not had a green build for nearly 120 days
>>    https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds
>> since Build #603...
>>    https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/200671152
>>
>> I'd guess that makes it harder to identify which "new" commits introduce
>> "new" defects.
>> It was tough for me trying to categorise the historical failures to
>> understand what might be required to make them green.
>>
>> For example, lately the usual failure has been just a single job...
>>     macos32x64 squeak.sista.spur.
>> which last worked 22 days ago in Build #713
>>    https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/228902233
>> but there are other failures in builds that obscure that fact, way back
>> to #603.
>> Only an exhaustive search through all builds reveals this.
>>
>> For example, recent Build #748 has macos32x64 squeak.sista.spur as its
>> only failure
>>    https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/236010112
>> but then #750,#751, #752, #753 introduce other failures.
>>
>> Perhaps a contributing factor is commits being pushed directly to the
>> server Cog branch,
>> with CI tests only running after they are integrated.  I guess that was
>> done to keep the workflow
>> similar for those moving from subversion to git.   However it seems to
>> lose some value of CI
>> in "preventing" build failures from entering the repository.   After a
>> year of using git maybe
>> this workflow could be reconsidered? Perhaps turn turn on branch
>> protection for administrators
>> and "force" all commits to the server Cog branch to first pass CI
>> testing?
>>
>> Of course needing to submit everything via PRs adds workflow overhead,
>> but some workflows might minimise the impact.
>> So I can't argue whether the benefit is worth it, since I'm not working
>> in the VM every day.
>> I'm just bumping the status quo to table the question for discussion.
>>
>> cheers -ben
>>
>> P.S. Should macos32x64 squeak.sista.spur be fixed, or temporarily removed
>> from the build matrix?
>> A continually failing build seems to serve no purpose, whereas green
>> builds should be a great help to noticing new failures.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170528/6192f07c/attachment.html>