I’ve actually determined the issue, here.
Here is what is happening:
- a developer pushes code in a new branch. that branch has logic in .circleci/config.yml to inspect the CIRCLE_PULL_REQUEST env var
- circleci kicks off a build for this branch
- circleci runs the workflow that looks for CIRCLE_PULL_REQUEST and it fails, because the branch is not part of a PR
- the developer then creates a PR for the above branch
- circleci looks and sees that a build has already been started for this branch, at the same commit. therefore, it chooses to associate those builds with this PR. As a result, it ends up attaching a failed build to the PR.
#5 is the problem. CircleCI should not be associating the build from the push to the branch with the PR, specifically because the variables like CIRCLE_PULL_REQUEST can be used to change workflow behavior. Other systems, like Jenkins, will kick off a build for the PR separate from the push to the branch for this very reason.
Unless I’m wrong about the above (and I don’t think I am), I would say this is a design mistake in CircleCI.