Incorrect `isPr` value for CircleCi
dannyrb opened this issue · comments
Here: https://github.com/pvdlg/env-ci/blob/master/services/circleci.js#L10-L11
Per https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables, CIRCLE_PULL_REQUEST may be set for a run triggered by a PR merge, even if the run is against the target of the merge.
🎉 This issue has been resolved in version 3.2.2 🎉
The release is available on:
Your semantic-release bot 📦🚀
This may not fix the problem. In fact it broke my workflow. semantic-release/semantic-release#1166 (comment)
So while CIRCLE_PR_NUMBER will only appear on forked PRs, that is not the case for CIRCLE_PULL_REQUEST. The excerpt "If there are multiple associated pull requests..." also seems to indicate that this value may be set for jobs run when a branch has merged changes.
This works for forks, but now you completely removed the ability to detect a PR from a branch within the same repository.
CIRCLE_PULL_REQUEST alone = PR from a branch within the same repo
CIRCLE_PULL_REQUEST + CIRLCE_PR_NUMBER = PR from a fork
As far as I can tell. Could be more clear from the circle side, sure but yea...
@pvdlg Let me know if you'd like me to open a new issue.
So what's the proper code to determine if the job is running on a PR?
Your previous logic was correct.
The reporter of the issue had a pull-request open associated with the branch react. Therefore circle considered it a "PR" -- which it was, technically. Any continual work pushed to that branch would be considered a "PR", so long as a PR is open in GitHub for that branch.
If you push a branch to your repository, without an associated open PR, CircleCI will not associate it as a pull request. You will not see CIRCLE_PULL_REQUEST or CIRCLE_PR_NUMBER.
My recommendation? Revert to your previous logic.
Also commented on the sem-rel issue: semantic-release/semantic-release#1166 (comment)