check step fails after upgrade from jtarchie/github-pullrequest-resource

[willmurphyscode]

I am building a new pipeline that needs to check GitHub pull requests. I had this portion working running with jtarchie/github-pullrequest-resource, but after switching to this pr resource, I am experiencing the following failure in the resource:

resource script '/opt/resource/check []' failed: exit status 1

stderr:
2019/01/03 02:03:13 failed to unmarshal request: json: unknown field "ref"

Running fly check-resource produces basically the same output.

I don't have any usual configuration at all, so I expected this to just work (after changing repo to repository). Here's my configuration for the resource:

resource_types:
- name: pull-request
  type: docker-image
  source:
    repository: teliaoss/github-pr-resource

resources:
- name: cli
  type: pull-request
  check_every: 1m
  source:
    repository: cloudfoundry/cli
    access_token: ((github-access-token))
    ignore_paths:
    - README.md
    - .github/

The access token gets interpolated correctly, and has the following scopes: repo/repo:status and repo/public_repo. The repository itself is public.

Any help would be appreciated. It seems to me that the check script is getting JSON back with an unexpected key, and I'm not sure how to address that. Has anyone seen this particular error message before?

[itsdalmo]

Hi and thanks for submitting!

The issue you are seeing is related to this line which was added in v0.9.0 (if you try v0.8.0 it should work). It causes check to fail because ref is not a part of the version in this resource, but it is being passed a previous version which was created by the old resource (which does contain ref).

The best way to solve this is to rename the cli resource in your pipeline definition, and you'll start with a clean version history which works for subsequent checks.

[willmurphyscode]

@itsdalmo Thanks so much for the quick response. Renaming the resource made it start working. Interestingly, renaming it back broke it again, but I was able to just delete and re-create the entire pipeline, which fixed everything without having to live with a permanent rename.

Also, it looks like Concourse will make it so that changing the type of a resource clears its history without having to rename it: concourse/concourse#145

Would you consider mentioning this particular problem here: https://github.com/telia-oss/github-pr-resource#migrating ? It seems like a lot of people might try to take the migration path I did, and the solution was, at least for me, pretty surprising. (Also, I am happy to PR this change to the README if you'd like.)

[itsdalmo]

Great to hear that it's working again! Was not aware of the issue you linked, but thats great news!

If you have time to do the PR to improve the docs that would be great! Feel free to restructure it also if you need to🙌

[gabro]

We've had the same problem and we solved by manually deleting the old cache entries from the database. It would be great it there could be a different workaround that didn't include to either manually fiddle with the db or renaming the resource (which requires updating every reference to it in the pipeline), but it seems newer version of Concourse will fix this by design :)