[Vm-dev] the purpose of CI
lists at fniephaus.com
Sun May 28 19:48:20 UTC 2017
+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" .
On Sun, May 28, 2017 at 4:20 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:
> Exactly what I named continuous desintegration in recent post
> 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
>> since Build #603...
>> 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
>> 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
>> 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
>> 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...
More information about the Vm-dev