<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">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><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> <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>