Skip to content

Commit

Permalink
ci: only run CI on master and auto
Browse files Browse the repository at this point in the history
  • Loading branch information
BurntSushi committed Dec 30, 2017
1 parent 918d4a0 commit 2b4ac35
Show file tree
Hide file tree
Showing 2 changed files with 8 additions and 2 deletions.
4 changes: 4 additions & 0 deletions .travis.yml
Original file line number Diff line number Diff line change
Expand Up @@ -26,3 +26,7 @@ env:
notifications:
email:
on_success: never
branches:
only:
- master
- auto
6 changes: 4 additions & 2 deletions appveyor.yml
Original file line number Diff line number Diff line change
Expand Up @@ -10,8 +10,10 @@ install:
- SET PATH=%PATH%;C:\MinGW\bin
- rustc -V
- cargo -V

build: false

test_script:
- cargo test --verbose --jobs 4
branches:
only:
- master
- auto

6 comments on commit 2b4ac35

@RalfJung
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this mean you are running tests twice? Once when the PR gets pushed to auto by bors, and then again when bors moves it to master?

AFAIK the usual setup is to only run on auto and try. You only need master CI if you want it to run in PRs (and then it should probably condition on really being in a PR).

@BurntSushi
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. I stopped using bors a long time ago because I found it to be a pain in the ass for a low traffic repo like regex. I was using bors though, so the auto branch here is vestigial.

@RalfJung
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, thanks. :)

AppVeyor still runs twice, once for PRs and once when it lands in master, but for low-traffic repos that won't contribute much to our overall AppVeyor load. (All rust-lang-libs projects share a single AppVeyor runner, and that can be quite congested these days.)

@BurntSushi
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that is intentional. Travis should be doing the same thing. That ensures both the PR and the result of merging the PR are checked in CI. bors is better here because it checks the result of the merge before actually merging it.

(The other reason I don't like bors is because it, AIUI, forces you to use merge commits and I don't like merge commits.)

@RalfJung
Copy link
Member

@RalfJung RalfJung commented on 2b4ac35 Jul 1, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(The other reason I don't like bors is because it, AIUI, forces you to use merge commits and I don't like merge commits.)

Current bors does, yes, though that doesn't seem fundamental to the approach.

I quite like the merge commits actually, but YMMV (and clearly does). ;)

There's still regex bors config at https://github.com/rust-lang/rust-central-station/blob/b883b4799fbaf83765fb5c10d16be1f8b529b0aa/homu.toml.template#L201 btw, might be better to remove it then?

@BurntSushi
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had no idea that repo existed. (Looks like it didn't back when I was using bors. :P) In any case, I submitted a PR: rust-lang/rust-central-station#280

Please sign in to comment.