CIRCLE_PULL_REQUESTS environment variable not being set

Build Environment
1

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

2

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
3

@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?

4

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.

1 Like
5

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
2 Likes
6

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.

1 Like
7

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
8

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.

9

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.

1 Like
10

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
11

So other than something similar to the above work around I take it CircleCI is ignoring this?

12

I have exactly the same issue. I create a pull request and CircleCI does not set the env var hence my testing script does not run as it is supposed to stop when it’s not a pull request. Clicking on the Run again button in the GUI however sets the pull request environment variable and executes all my tests.

Isn’t there a way to escalate this?

1 Like
13

Hi @ir-fuel. Thanks for bringing this issue back to life. I’m asking around now to see what can be done about this, and who might have the ability to prioritize it.

14

I’ve got an open ticket on your side about this.

1 Like
15

If it can help, I was about to open a ticket about the same issue.
And in my case, it is a bit a deal-breaker, because the PR value is used to properly configure the extend of the build. Without PR id, it triggers a full build which takes quite some times and involves large machines. Thus, such a build costs much more than expected, making it more important than a mere annoyance.