-
Notifications
You must be signed in to change notification settings - Fork 437
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-clearing the AppVeyor queue backlog #1938
Comments
Hi @effigies,
Thank you really much for this! It makes me crazy too. We are thinking to move to Azure and leave Appveyor, they allow 10 parallel jobs / illimited time on Windows for opensource software. I will set up that for the release 1.1.
Unfortunately, I do not have access to the
Thank you for pinging us and feel free to cancel some builds until we manage to update our AppVeyor settings |
Same. Anything beyond working with a few PRs a day is just unmanageable with AppVeyor. |
I just came to look into asking y'all to enable this. Been waiting 3h and counting for a PySurfer PR to run... I have admin rights for the Nipy org on AppVeyor so I enabled this for dipy. Let me know if you want me to revert. |
Sorry for that...
Thank you! |
closing since we use Azure pipelines now. |
Description
Hi all. DiPy has a pretty long build, which can end up causing congestion for other nipy projects when a lot of commits are pushed in a relatively short period, particularly for AppVeyor, which only gets one simultaneous job.
Occasionally if the queue is getting long, I will kill the builds for all but the most recent commits on AppVeyor, so each PR will not build superseded commits. (I leave master alone.) Apologies if this is abusing a privilege I have, but right now, for instance, there is a queue of 3 hour builds that would be 15 deep if I didn't do this, and now it's down to 7, which will still take most of a day. I assume you don't actually need every commit built.
I know Travis has a setting to auto-cancel jobs on PRs that are superseded by later commits, and I looked into this in AppVeyor. They're called rolling builds, and can be configured in https://ci.appveyor.com/project/nipy/dipy/settings.
For nibabel I'm trying out these settings:
I think this will reproduce my policy, which is to cancel all but the most recent commit, except master, which I'll cancel manually if I'm merging a lot at once.
Anyway, just something for y'all to consider when you get time. It took digging for me to find this, because of the unintuitive name, so I thought I'd share. And feel free to tell me to stop cancelling your jobs if you really do want them all built.
The text was updated successfully, but these errors were encountered: