I personally feel pretty strong that this is not a bug. This feels a sensible default behaviour and implementation to behave this way.

By that I mean: you filed it as an "Important bug", and I'm sure that if this was fixed, someone seeing the reverse behaviour would also judge it as a bug. It looks more like a specific behaviour request to me.

So, it could be filed as an improvement request to allow behaving the alternate behaviour. But FWIW boon I tend to think that if you don't bite the bullet yourself to propose this improvement as a PR, this won't get fixed anytime soon by someone else.

Just my 2 cents.

batmat except that there has been a "Disable" feature available for "non-pipeline" projects for years now and it didn't remove builds from queue.

batmat I disagree that is sensible behaviour. Why just remove the next build? What not all queued builds? The feature is "Disable" not "Disable and Purge", there is already a dedicated option for purging a job's build queue.

In general, I think the queue should not be touched when disabling a job. From experience, I may need to temporarily disable a job to prevent new builds from being triggered, fix a bug in the job's configuration, and then resume the queue.

I'm working on some improvements to GitHub Branch Source, so I don't currently have the time to work on a fix. Either way, the bug needs to be reported.

TBH I consider disabling a project and it not getting scheduled builds removed from the queue a bug, not this behavior. If we're looking for consistency, the other one should be changed.

danielbeck I think not removing the queue would be the more flexible choice and cater for more users. If a user wishes to remove the queue they can just select the Purge option.