appveyor queue is too long
Locked
 
|
Hi all, didn't we configure appveyor to cancel the builds when a newer commit is performed in the same branch/PR? Currently, job queue is too deep (and slow) |
Re: appveyor queue is too long
|
|
Or maybe we don't interrupt jobs that already started? Le mer. 2 janv. 2019 à 15:44, Nicolas Cellier <[hidden email]> a écrit :
|
|
On Wed, 2 Jan 2019 at 3:46 pm, Nicolas Cellier <[hidden email]> wrote:
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).
|
Re: appveyor queue is too long
|
|
Reminder: we also have [skip travis] and [skip appveyor] when we only change platforms specific files, or build instructions. Le mer. 2 janv. 2019 à 16:15, Fabio Niephaus <[hidden email]> a écrit :
|
Re: appveyor queue is too long
|
|
All this take really a long time. Are the stack build really necessary? 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). Is it possible to trigger the build on specific changes? I wonder if we could not arrange to have another subproject that would build those alternative VM... Le mer. 2 janv. 2019 à 17:13, Nicolas Cellier <[hidden email]> a écrit :
|
|
|
On Thu, Jan 3, 2019 at 12:31 PM Nicolas Cellier <[hidden email]> wrote:
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.
|
Re: appveyor queue is too long
|
|
Le jeu. 3 janv. 2019 à 13:23, Fabio Niephaus <[hidden email]> a écrit :
+1
|
|
|
On Thu, 3 Jan 2019 at 21:58, Nicolas Cellier <[hidden email]> wrote:
You could maybe have another travis account, much like I recently set one up for myself... https://travis-ci.org/bencoman/opensmalltalk-vm/builds I've tried searching for whether Travis would have a problem with that and not been able to find anything.
Sounds okay, but before you run with that, just another idea to consider... I see the main issue is the delay when trying to iterate on a PR. So perhaps the way forward is that PRs only the eight "main" platforms, providing a 10 minute iteration. 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. It seems this could be configured using conditional stages... Also it seems any incoming PR-build could auto cancel the Cog-branch full-build, thus ensure that doesn't get in the way of fast PR iterations. A side benefit might be encouraging discipline in submitting all changes via PR. Even if the developer creating the PR immediately merges it themselves, a PR provides nice mechanism to group related commits, and also provides a nice place to hang comments, even after merging. No need anyone current committing directly to Cog to wait for those comments. cheers -ben
|
Re: appveyor queue is too long
|
|
Le jeu. 3 janv. 2019 à 15:26, Ben Coman <[hidden email]> a écrit :
side note: another grief is that PR which are just fast-forward merge triggers 2 builds... I did not inquire if there was a solution for that.
|
Re: appveyor queue is too long
|
|
In reply to this post by Nicolas Cellier
Also CONTRIBUTING.md should start with a table of contents. It is nearly tl;dr
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |