PR metadata is not found when using cloudfoundry-community/github-pr-resource instead of telia-oss/github-pr-resource

[cedoucette]

I tried to add a step to my PR builder Concourse CI job that integrates with SonarQube.
However, when I added it, I got this error:
ERROR in /opt/resource/out : line 203 with exit code 1
Here is line # 203 of the out file.

Here is the most likely reason that the line failed.

I think this should be an easy issue to resolve. I may add a PR to resolve it myself. Perhaps users should also be able to provide that PR metadata information as a parameter so that this resource type wouldn't have to be changed.

I am actually not sure which github-pr-resource type that we are using. Please note that the Concourse CI resource types page is recommending this resource type for github-pr (instead of this resource type).
I realize that is likely not one that is compatible (e.g. telia-oss/github-pr-resource).

[cedoucette]

Apparently my gihub-pr-resource was forked from telia-oss/github-pr-resource . So, that was not the issue.
When I added the parameter of decorate_pr, it tried many ways to find the PR meta data:

1. if [ -f "${project_path}/.git/resource/metadata.json" ]; then
2. elif [ -f "${project_path}/pull-request-info" ]; then
3. else \ pr_id=$(git config --get pullrequest.id)

It was falling through to the last if statement - and the pull request metadata was not available via git config. Thus, it failed. It turns out the issue was that I hadn't been setting the parameter project_path. Somehow, this wasn't detected or reported as an error, even though there is clearly code to do that (perhaps that is a subject of another issue). Once it was set, the PR meta data was available, and decorate_pr worked fine.

I have a few comments about this issue:

1. The first if statement should also check for the existence of ${project_path}/.git/resource/version.json, since that file is also expected/searched for the pr_id.
2. The last if statement should ensure that the pull request meta data is available via something like: git config --list | fgrep pullrequest
3. Since you already support these parameters - shouldn't they also be used in decorate_pr handling: a) branch_name, b) branch_name_file, c) branch_target, d) branch_target_file?

Thus, although this code should be cleaned up, it is no longer a blocking issue and can be at least postponed and perhaps closed (user error).