Using Custom Resource - aequitas/http-api-resource causes build details (events endpoint) to not load

[pranaysharmadelhi]

Bug Report

When using custom resource aequitas/http-api-resource the build does not load the events endpoint (as per network tab) and UI stays at "loading" state forever.

The following can also be handy:

• Concourse version:v3.5.0
• Deployment type (BOSH):
• Infrastructure/IaaS: Azure
• Browser (if applicable): Chrome (MAC)
• Did this used to work? No https://github.com/concourse/concourse/issues/1977

[aequitas]

Is this since any of the recent releases?

[pranaysharmadelhi]

Yes, using the latest one

[aequitas]

But did you use the plugin before or have you just started using it recently?

Also could you share the relevant configuration parts and any log output?

[pranaysharmadelhi]

This is the first time I'm using this plugin. Here is the pipeline configuration -

resource_types:
- name: http-api
  type: docker-image
  source:
    repository: aequitas/http-api-resource
    tag: latest

resources:
- name: deploy-dev
  type: http-api
  source:
      uri: https://apps.pipipeline-node.com/fly
      method: POST
      debug: true
      ssl_verify: false
      json:
        buildTeamName: "{BUILD_TEAM_NAME}"
        buildId: "{BUILD_ID}"
        buildName: "{BUILD_NAME}"
        buildJobName: "{BUILD_JOB_NAME}"
        buildPipelineName: "{BUILD_PIPELINE_NAME}"

- name: cf-push-dev
  serial: true
  public: true
  plan:
  - aggregate:
    - get: gitfolder
      resource: git-develop
      trigger: true

  - task: assemble
    file: gitfolder/concourse/assemble.yml
    params:
        TERM: xterm
        NPM_REGISTRY: {{npm_registry}}
        NPM_AUTH: {{npm_auth}}
        NPM_EMAIL: {{npm_email}}
        NPM_SASS_BINARY_SITE: {{npm_sass_binary_site}}

  - put: deploy-dev

[aequitas]

Could you use code blocks for the config to make it properly readable?

[pranaysharmadelhi]

Updated yml code block above

[aequitas]

Thx, looks alright to me. Can you see if there is any logging on the server that might help debugging? I believe both frontend and worker output a lot of information to logs.

[scottasmith]

The reason this breaks is that its not returning correct JSON back to concourse.

One way to see what is happening is to open the debug console in the browser and see something similar to this error:

failed to fetch plan: BadPayload "Expecting an object at _.inputs[0].version but instead got: null" ......

When you return JSON from the resource.py line 85 you must return something in the version. The version hash "version": {} has to have a value (it can be a timestamp or hash for all it cares)

[pranaysharmadelhi]

Thanks @scottasmith . You are correct. @aequitas , could you please update the resource.py to return proper version so it does not crash Concourse UI?

[pranaysharmadelhi]

Hardcoded a static timestamp version, but still getting error

response = {"version": {"version": "1517360058"}}

Error: failed to fetch plan: BadPayload "Expecting an object at _.inputs[0].version but instead got: null

[pranaysharmadelhi]

The issue seems to be with resource also showing up under "input" instead of being only in output. The version field in "input" is null, @scottasmith any idea where/how to fix that?

[scottasmith]

Sorry my bad, its your assets/check and assets/in that are incorrect.

I have a repo concourse-deploy-resource that just sends {"version":{"ref":"none"}} back for both.

Mine are in bash, but exactly the same JSON string:

• https://github.com/scottasmith/concourse-deploy-resource/blob/master/assets/check
• https://github.com/scottasmith/concourse-deploy-resource/blob/master/assets/in

[pranaysharmadelhi]

Can you please verify if changes reflect on Docker. The build seemed to fail - https://store.docker.com/community/images/aequitas/http-api-resource/builds

[scottasmith]

@pranaysharmadelhi I don't understand. You can't update someone else's docker images. I have submitted a pull request of a working branch.

[aequitas]

@pranaysharmadelhi I missed the notification on that build failing, but that was no change to the content of the resource, only a file to automate testing for future pullrequests.

@scottasmith the failing Docker Hub build is not related to your change, but new pullrequest updates will not trigger a Travis build which will show test results.

[scottasmith]

@aequitas No, maybe not. But submitting a failing pull request multiple times instead of testing on your own branch until it works is not good practice!

[aequitas]

I don't mind failing PR's. I setup the Travis build as a utility for both me and you :). For me to know if a PR can safely be merged and for you so you can check the same without doing the effort of setting up the build yourself.

[aequitas]

Fixed in #12

[scottasmith]

Just tried this in my environment and can confirm it works.

Strangely, if the version is empty (not null) the input is not included in the input list in the console.

[aequitas]

I think because if there is no input that should be no input. But I'd have to dive into Concourse again to get a little familiar with the conventions and what makes sense from a conceptual point of view.