Just a thought on refining the jobs in the CI build queues when dealing with PRs. Frequently people are tweaking their PRs based on the quick feedback from the community (thanks for being so great everyone :smile:). Unfortunately, this results in CI backlog of builds particularly for the slower ones (namely AppVeyor, sometimes Travis, very rarely Circle). It would be good if we just "pushed" the cancel button. I do this manually to some extent, but it is hard to keep up with and not always a good use of time. It is not obvious to me where this would run. Though putting it on the fastest of the CIs would make sense (so Circle). Thoughts? Other ideas?
Yeah I totally agree. I remember mentioning something about this before - in terms of the fact that Appveyor is crazy slow!
One option is to have a Github webhook running somewhere that gets notified when a PR receives a new commit - it can then check (using the APIs for the CIs) if a build is running for that PR and terminate it if necessary?
Could start with designing something to run on something like digital ocean and then maybe we could be cheeky and see if continuum would host something for us?
One option is to have a Github webhook running somewhere that gets notified when a PR receives a new commit - it can then check (using the APIs for the CIs) if a build is running for that PR and terminate it if necessary?
Nice! This idea sounds simple and effective. Probably the easiest to implement. It also runs exactly when needed and no more. :+1:
Could start with designing something to run on something like digital ocean and then maybe we could be cheeky and see if continuum would host something for us?
Could work. There has been some discussion about getting sponsorship from NumFOCUS for AppVeyor builds. It's possible Continuum may chip in. Before going to either of them though it would be nice to say we have made our best effort at culling the build queues, which has been something we have been working on. Admittedly, we may need help to do that. Though I think we might be able to leverage Circle CI to do this.
Let's see if anybody else has thoughts.
When looking around here are somethings I saw this for terminating Travis CI PR build duplicates. Maybe something in there could help inspire us here.
We added this in https://github.com/conda-forge/conda-smithy/pull/74. It needs to be rolled out across the feedstock estate. The software infrastructure exists to generate PRs for every single feedstock, which then has to be merged by feedstock maintainers. I'm going to try to get the AppVeyor hook working first (to skip those without appveyor.yml), but will then be proposing >160 PRs :wink:
Ironically, to avoid backlogging the CI, I'll submit them in smaller batches.
I really like this idea, but don't think it has the priority that it did before we had our AppVeyor account upgraded (and we added the self culling code to the AppVeyor builds).
I definitely don't think this needs to stay open on this repo. If we want to move it forwards, maybe we could open an issue on https://github.com/conda-forge/conda-forge.github.io/issues?
Sure, I think we can close this for now. We can always revisit these sorts of things if we run into more issues.
Most helpful comment
Yeah I totally agree. I remember mentioning something about this before - in terms of the fact that Appveyor is crazy slow!
One option is to have a Github webhook running somewhere that gets notified when a PR receives a new commit - it can then check (using the APIs for the CIs) if a build is running for that PR and terminate it if necessary?
Could start with designing something to run on something like digital ocean and then maybe we could be cheeky and see if continuum would host something for us?