We turned on 2.1 because we were eager to take advantage of triggering workflows via API and auto-canceling of redundant workflows. Those worked great, but we noticed an issue with how the “Only build pull requests” setting behaves under 2.1. In particular, it looks like its not running workflows that it should.
Here’s an example,
In 2.0 with Only build pull requests enabled and Enable build processing (preview) disabled,
Create a branch foobar
Push the branch to Github
Notice that the workflow is Not Run, as expected
Open a pull request for foobar
Notice that the workflow is now running, as expected
In 2.1 with Only build pull requests enabled and Enable build processing (preview) enabled,
Create a branch foobar
Push the branch to Github
Notice that the workflow is Not Run, as expected
Open a pull request for foobar
Notice that the workflow is still Not Run, which is not expected
Lemme know if this is indeed a bug or if I can clarify anything else about our setup. Its a fairly vanilla 2.0 workflows .circleci/config.yaml
I’d also like to note another case where this was problematic for us. We recently had a PR go into master on a project that caused a regression. Our typical course of action if it’s not an issue requiring an immediate hotfix is to revert the PR, wait for the revert PR on GitHub to pass our status checks (including CircleCi) before merging.
Since creating a revert PR from GitHub’s UI is a two step operation (first click creates the branch, second click creates the PR after filling in any labels, description, etc) our revert PRs won’t run their workflow under Circle 2.1 due to the aforementioned issue. I tested with the 2.1 setting disabled and got the correct behavior.