<div dir="ltr">+1 for using more (feature) branches for OSVM development<div><br><div><div>Also, there's no need to temporarily remove a build. We can flag builds as "allow to fail" [1].</div><div><br></div><div><br></div><div>[1] <a href="https://docs.travis-ci.com/user/customizing-the-build#Rows-that-are-Allowed-to-Fail">https://docs.travis-ci.com/user/customizing-the-build#Rows-that-are-Allowed-to-Fail</a></div><div><br><div class="GmSign">-- <br></div><br><div class="gmail_quote"><div dir="ltr">On Sun, May 28, 2017 at 4:20 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr"><div>+1<br><br>Exactly what I named continuous desintegration in recent post<br><a href="http://forum.world.st/OpenSmalltalk-opensmalltalk-vm-24bea9-Fix-compilation-of-SoundPlugin-on-Windows-td4947979.html" target="_blank">http://forum.world.st/OpenSmalltalk-opensmalltalk-vm-24bea9-Fix-compilation-of-SoundPlugin-on-Windows-td4947979.html</a><br><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-05-28 15:46 GMT+02:00 Ben Coman <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="ltr"><div><br></div>Maybe I'm speaking out of turn from the sidelines, but just curious to ask a leading question... <div><br></div><div>What is the purpose of the Continuous Integration system?</div><div><br></div><div><br></div><div><br></div><div>I notice Travis has not had a green build for nearly 120 days</div><div>   <a href="https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds" target="_blank">https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds</a><br></div><div>since Build #603...<br></div><div>   <a href="https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/200671152" target="_blank">https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/200671152</a><br></div><div><br></div><div>I'd guess that makes it harder to identify which "new" commits introduce "new" defects.</div><div>It was tough for me trying to categorise the historical failures to understand what might be required to make them green.  </div><div><br></div><div>For example, lately the usual failure has been just a single job... </div><div><div>    macos32x64 squeak.sista.spur.</div></div><div>which last worked 22 days ago in Build #713 </div><div>   <a href="https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/228902233" target="_blank">https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/228902233</a><br></div><div>but there are other failures in builds that obscure that fact, way back to #603.</div><div>Only an exhaustive search through all builds reveals this.</div><div><br></div><div>For example, recent Build #748 has macos32x64 squeak.sista.spur as its only failure </div><div>   <a href="https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/236010112" target="_blank">https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/236010112</a><br></div><div>but then #750,#751, #752, #753 introduce other failures.</div><div><br></div><div>Perhaps a contributing factor is commits being pushed directly to the server Cog branch, </div><div>with CI tests only running after they are integrated.  I guess that was done to keep the workflow</div><div>similar for those moving from subversion to git.   However it seems to lose some value of CI</div><div>in "preventing" build failures from entering the repository.   After a year of using git maybe </div><div>this workflow could be reconsidered? Perhaps turn turn on branch protection for administrators</div><div>and "force" all commits to the server Cog branch to first pass CI testing? </div><div><br></div><div>Of course needing to submit everything via PRs adds workflow overhead, but some workflows might minimise the impact.</div><div>So I can't argue whether the benefit is worth it, since I'm not working in the VM every day. </div><div>I'm just bumping the status quo to table the question for discussion. </div><div><br></div><div>cheers -ben</div><div><br></div><div>P.S. Should macos32x64 squeak.sista.spur be fixed, or temporarily removed from the build matrix?</div><div>A continually failing build seems to serve no purpose, whereas green builds should be a great help to noticing new failures. </div><div><br></div></div>
<br></blockquote></div><br></div>
</blockquote></div></div></div></div></div>