<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 3 Jan 2019 at 21:58, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">Le jeu. 3 janv. 2019 à 13:23, Fabio Niephaus <<a href="mailto:lists@fniephaus.com" target="_blank">lists@fniephaus.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 3, 2019 at 12:31 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div>All this take really a long time. Are the stack build really necessary?</div><div>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).</div><div>Is it possible to trigger the build on specific changes?<br></div><div>I wonder if we could not arrange to have another subproject that would build those alternative VM...<br></div></div></blockquote></div></div></blockquote></div></div></blockquote><div><br></div><div>You could maybe have another travis account, much like I recently set one up for myself...<br><a href="https://travis-ci.org/bencoman/opensmalltalk-vm/builds">https://travis-ci.org/bencoman/opensmalltalk-vm/builds</a><br></div><div><br></div><div>I've tried searching for whether Travis would have a problem with that and not been able to find anything.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div></blockquote><div><br></div><div>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.</div><div> </div></div></div></blockquote><div>+1</div></div></div></blockquote><div><br></div><div>Sounds okay, but before you run with that, just another idea to consider...</div><div><br></div><div>I see the main issue is the delay when trying to iterate on a PR. </div><div>So perhaps the way forward is that PRs only the eight "main" platforms, providing a 10 minute iteration.</div><div>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. </div><div><br></div><div>It seems this could be configured using conditional stages...<br></div><div><div> <a href="https://docs.travis-ci.com/user/conditional-builds-stages-jobs/">https://docs.travis-ci.com/user/conditional-builds-stages-jobs/</a><br></div><br class="gmail-Apple-interchange-newline"></div><div>Also it seems any incoming PR-build could auto cancel the Cog-branch full-build,</div><div>thus ensure that doesn't get in the way of fast PR iterations. </div><div> <a href="https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation">https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation</a></div><div><br></div><div>A side benefit might be encouraging discipline in submitting all changes via PR.</div><div>Even if the developer creating the PR immediately merges it themselves, a PR provides nice mechanism to group related commits, </div><div>and also provides a nice place to hang comments, even after merging.</div><div>No need anyone current committing directly to Cog to wait for those comments. </div><div><br></div><div>cheers -ben</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 2 janv. 2019 à 17:13, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Reminder: we also have [skip travis] and [skip appveyor] when we only change platforms specific files, or build instructions.</div><br><div class="gmail_quote"><div dir="ltr">Le mer. 2 janv. 2019 à 16:15, Fabio Niephaus <<a href="mailto:lists@fniephaus.com" target="_blank">lists@fniephaus.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, 2 Jan 2019 at 3:46 pm, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" rel="noreferrer" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr">Or maybe we don't interrupt jobs that already started?</div></blockquote><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 2 janv. 2019 à 15:44, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" rel="noreferrer" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Hi all,</div><div>didn't we configure appveyor to cancel the builds when a newer commit is performed in the same branch/PR?</div><div><br></div><div>Currently, job queue is too deep (and slow)<br></div><div><a href="https://ci.appveyor.com/project/OpenSmalltalk/vm/history" rel="noreferrer" target="_blank">https://ci.appveyor.com/project/OpenSmalltalk/vm/history</a><br></div></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div></div></div></div>