-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Only run AppVeyor on r+, try and the master branch #4028
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
Conversation
As it is right now, there is only one worker available in the `rust-lang-libs` AppVeyor project and there are other repos as well that we share this worker with. This has been a problem for us because we sometimes hit a bors timeout if there are too many builds queued up. To improve the situation, I think we could try to use AppVeyor a bit less often. The average PR is not going to break windows related things anyway, so it should be fine to run it on r+/try/master only.
It seems the PR is still being built even with the updated branch restrictions? |
AFAICT someone with permissions has to check 'Do not build on "Pull request" events' near the bottom at https://ci.appveyor.com/project/rust-lang-libs/rust-clippy/settings |
Done. |
Looks like it works. Only Travis has been triggered by the re-open =) Thanks @Manishearth! @bors r+ |
📌 Commit 8d7a5fe has been approved by |
Only run AppVeyor on r+, try and the master branch As it is right now, there is only one worker available in the `rust-lang-libs` AppVeyor project and there are other repos as well that we share this worker with. This has been a problem for us because we sometimes hit a bors timeout if there are too many builds queued up. To improve the situation, I think we could try to use AppVeyor a bit less often. The average PR is not going to break windows related things anyway, so it should be fine to run it on r+/try/master only.
💡 This pull request was already approved, no need to approve it again.
|
📌 Commit 8d7a5fe has been approved by |
Only run AppVeyor on r+, try and the master branch As it is right now, there is only one worker available in the `rust-lang-libs` AppVeyor project and there are other repos as well that we share this worker with. This has been a problem for us because we sometimes hit a bors timeout if there are too many builds queued up. To improve the situation, I think we could try to use AppVeyor a bit less often. The average PR is not going to break windows related things anyway, so it should be fine to run it on r+/try/master only.
💔 Test failed - status-appveyor |
@bors retry |
Only run AppVeyor on r+, try and the master branch As it is right now, there is only one worker available in the `rust-lang-libs` AppVeyor project and there are other repos as well that we share this worker with. This has been a problem for us because we sometimes hit a bors timeout if there are too many builds queued up. To improve the situation, I think we could try to use AppVeyor a bit less often. The average PR is not going to break windows related things anyway, so it should be fine to run it on r+/try/master only. changelog: none
☀️ Test successful - checks-travis, status-appveyor |
As it is right now, there is only one worker available in the
rust-lang-libs
AppVeyor project and there are other repos as well that we share this worker
with. This has been a problem for us because we sometimes hit a bors timeout if there
are too many builds queued up.
To improve the situation, I think we could try to use AppVeyor a bit less
often. The average PR is not going to break windows related things anyway, so
it should be fine to run it on r+/try/master only.
changelog: none