<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/<wbr>OpenSmalltalk/opensmalltalk-<wbr>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/<wbr>OpenSmalltalk/opensmalltalk-<wbr>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/<wbr>OpenSmalltalk/opensmalltalk-<wbr>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/<wbr>OpenSmalltalk/opensmalltalk-<wbr>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>