CIRCLE_PULL_REQUESTS environment variable not being set

On a master build, for a merged pull request, neither CIRCLE_PULL_REQUEST, no CIRCLE_PULL_REQUESTS variables are being set properly.

Here is an example build that is failing https://circleci.com/gh/resideo-platform/exemplar/4109 for this pull request https://github.com/resideo-platform/exemplar/pull/93

It appears that this has been an issue for almost 2 years

Hi Charles. Once merged it is no longer part of a pull request per the GitHub web hook and therefore we have no data regarding what PR is was part of.

1 Like

@drazisil

I’m having this same issue for non-merged PRs. Just as in CIRCLE_PULL_REQUEST _still_ not being set, the CIRCLE_PULL_REQUEST env var is not set when a PR is first created. The creation of the PR triggers a build, but the env var is not set or blank. Rebuilding causes the workflow to have CIRCLE_PULL_REQUEST set. This is obviously a bug in the build engine.

Why don’t you all build in delay / retry logic such that if an expected env var value is not found, your engine retries obtaining them before firing off the scheduled workflow / build?

I’ve actually determined the issue, here.

Here is what is happening:

  1. a developer pushes code in a new branch. that branch has logic in .circleci/config.yml to inspect the CIRCLE_PULL_REQUEST env var
  2. circleci kicks off a build for this branch
  3. circleci runs the workflow that looks for CIRCLE_PULL_REQUEST and it fails, because the branch is not part of a PR
  4. the developer then creates a PR for the above branch
  5. 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.

A better design for this would be one or more of the following:

  1. always kick off workflows specific to a PR, even if builds are already running for the same branch
  2. always kick off builds specific to the PR, and respect “Auto-cancel redundant builds” which is not being taken into account here – since subsequent builds aren’t being launched
  3. create an Advanced Setting named “Run Separate Pull Request Build” to enable #1, while respecting #2
1 Like

Maybe the docs could be updated to reflect this? They currently read:

The following environment variables are exported in each build

This could lead people to believe that CIRCLE_PULL_REQUEST would be available in each build.

I’m pretty sure there’s also a bug somewhere in the platform.

While most of my projects work as expected, I still have some projects where CIRCLE_PULL_REQUEST et al aren’t being set, under the following workflow:

  1. “Only build on PR” set to “OFF” (I’ve actually tried both settings, with no difference)
  2. Create a branch, push some commits to it
  3. Create a pull request from the branch against master
  4. Push more commits to the branch

Expectation:
CIRCLE_PULL_REQUEST is NOT set during no.2
CIRCLE_PULL_REQUEST IS set during no.4

Observed:
CIRCLE_PULL_REQUEST is NOT set during no.2 or no.4

I’ve opened a support issue already, but maybe someone on the forum can shed light sooner?

1 Like

Any findings on this? My team is trying to use the PR number param to then use the GitHub api to post back.

Version: 2.1
Expected Behavior: $CIRCLE_PULL_REQUEST returns the PR number which is actually available at the top of the page.

Nope, nothing productive from Circle support on this yet.
Apparently their engineers are “aware” of the issue, but they provided no timeline and no visibility.

Seems to be spreading to other projects now too, which is really cramping my game.

OK, I figured out a very crude workaround for the circle-bitbucket project I’m working on.
If the CIRCLE_PULL_REQUEST variable is not set, but you think it should be, you can query the VCS API directly to fetch it. This script is for bitbucket, but similar will work for github. BITBUCKET_USER and BITBUCKET_PASS are variables specific to my environment - replace with whatever auth is appropriate for you.

if [ $CIRCLE_BRANCH <> "master" ]; then
  echo "Double checking for PR on $CIRCLE_BRANCH to work around Circle platform bug"
  PR_NUMBER=`curl -X GET -u $BITBUCKET_USER:$BITBUCKET_PASS \
https://api.bitbucket.org/2.0/repositories/$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME/pullrequests/?q=source.branch.name%3D%22$CIRCLE_BRANCH%22 \
| grep -o 'https:\/\/api.bitbucket.org\/2.0\/repositories\/messageagency\/jcb\/pullrequests\/[0-9]*' \
| grep -o '[0-9]*$' | head -1`

  if [[ $PR_NUMBER =~ ^-?[0-9]+$ ]] ; then
    echo "Found PR ${PR_NUMBER}"
    # do whatever you need with the PR number here
    # ...
  fi
fi