Feature Request: isPullRequest about is-ci HOT 8 CLOSED

@sibiraj-s Oh yes, I was actually thinking to put this into ci-info. I forgot this issue was opened on the is-ci module. Then an is-pr module can depend on it just like is-ci currently does.

from is-ci.

@zixia The module is-pr have now been released to npm - please take it for a spin and let me know what you think 😃

It has support for the CI servers @sibiraj-s listed above, except Codeship.

The reason why Codeship isn't supported is because of this note I found when reading about its CI_PULL_REQUEST environment variable:

Note: The value of CI_PULL_REQUEST is false, and doesn’t indicate if a commit has a corresponding pull request, or if the build was triggered by a pull request. The variable exists because some third-party integrations require its existence.

from is-ci.

I think this is going to be tough to normalize across CI systems. Travis is easy because it's so tightly integrated with the GitHub workflow, but a lot of other CI systems approach this in a more generic way AFAIK. So I'm not really sure if this is feasible?

from is-ci.

Yes, also only few exposes the constants in the build Environment too.

@watson If this feature is going to be accepted. checkout the following env constants

• TRAVIS_PULL_REQUEST (boolean)
• CIRCLE_PULL_REQUEST
• APPVEYOR_PULL_REQUEST_NUMBER
• BUILDKITE_PULL_REQUEST
• CIRRUS_PR
• CI_PULL_REQUEST (codeship - boolean)
• PULL_REQUEST_NUMBER (semaphore)
• IS_PULL_REQUEST (shippable - boolean)
• TDDIUM_PR_ID (solano)

from is-ci.

Thank @watson for your reply, and thank @sibiraj-s very much for your supported CI and environment variables list!

I think this feature will be very useful for us when we are using a CI that integrated with GitHub PR workflow.

As we had already listed the supported CI and environment variables, how about let's implement an isPullRequest() method, which can return true/false if we are sure this is(or not) a PR under CI, or throw an Exception if there's a CI that does not support to identify the PR, so that the user will know he can not use isPullRequest in their CI?

from is-ci.

Yes, thank you @sibiraj-s for the great research. It's more commonly exposed than I feared.

I guess it doesn't hurt to expose this in some way with proper documentation about that it's not always supported.

I'm hesitant to throw an exception though 🤔 I'm thinking we instead could return null in the cases where it's not supported?

from is-ci.

Instead of having it here, Just a thought. why not a separate is-pr lib instead.

is-pr can have its own documentation for supported CI's.

from is-ci.

Awesome，I'll try it out later.

Thank you very much for creating those great modules!

from is-ci.