Get Pull Request ID by branch name or commit hash

[mgrachev]

Hi there!

Some CI-services don't provide information such as Pull Request ID. So, I decided to get Pull Request ID by branch name or commit hash.

[mgrachev]

@haya14busa What do you think about it?

[haya14busa]

I'm sorry for the late response. I think it might be a good idea as a fallback. Do you have some CI examples which don't support p-r number?

[optional]
@shogo82148 Can you review this PR?

[mgrachev]

I know at least the one CI service, which doesn't provide Pull Request ID - Vexor.

I have been using my patched version of reviewdog on Vexor since the previous November.
After that, I didn't have any problems with reviewdog on Vexor 😃

[mgrachev]

I've fixed all conflicts.

[haya14busa]

This is breaking changes and I'm wondering what should we do.
e.g. Travis CI runs 2 builds, commit and p-r build.
Prior to this change, reviewdog only works on p-r build.

@reviewdog/reviewdog Do you have any thought?

Maybe we can document this change and the user can suppress reviewdog on commit build?
Worst case, 2 reviewdog runs in parallel and post duplicated comments.

[mgrachev]

Done.

[shogo82148]

I think it is the CI's issue. You should send a feature request to vexor.io first.

As haya14busa say, this feature is a breaking change. So it should be opt-in feature, and enabled by an environment value (e.g. REVIEWDOG_GUESS_PULL_REQUEST) or reviewdog config file.

[mgrachev]

@haya14busa @shogo82148 Updated.

[haya14busa]

Sry for the late reply. I should have left comments earlier.

I don't like the idea to change the behavior by an environment variable. Environment variables should be used for passing API key, CI "environment" variable (like commit, pr-number, etc... in CI services) and configuration which doesn't change the behavior but changing target or something (e.g. GITHUB_API base endpoint).
(Actually, the last one might be good to set by command-line flag or some configuration file, but I decided to use env var before.)

Let's use the command-line flag instead. Also, as mattn said, reviewdog should exit with non-zero exit code if the user explicitly specifies the flag and couldn't find the p-r.

[mgrachev]

@haya14busa @mattn Updated with using the flag guess.

About exiting with a non-zero code. I don't think that it's a good idea because CI-services create not only PR-builds. Thus, tests will always fail for these builds.

I think reviewdog shouldn't do anything if it doesn't find Pull Request ID by the branch name and the commit SHA. And it should exit with the zero code.

[mgrachev]

@haya14busa What do you think about it? Do you have any comments?

[mgrachev]

@haya14busa Is there a chance to merge this PR? 🙏

[haya14busa]

I'm sorry for the late response.

I'm still not 100% sure that it's a good approach, but it should be useful for some cases and acceptable design.

Thank you for your contribution!