Bitbucket badge returns Invalid Response Data

[HariSekhon]

Are you experiencing an issue with...

shields.io

🐞 Description

This call results in a badge saying Invalid Response Data

https://img.shields.io/bitbucket/pipelines/harisekhon/diagrams-as-code/master?logo=bitbucket&label=BitBucket%20CI

I've compared this to much older well established repos I have which used to work and the same thing has started happening there although I'm not sure when it started but these definitely used to work, for example this one:

https://img.shields.io/bitbucket/pipelines/harisekhon/devops-bash-tools/master?logo=bitbucket&label=BitBucket%20CI

which you can see here hasn't been changed in 3 years:

https://github.com/HariSekhon/DevOps-Bash-tools/blame/master/README.md#L82

🔗 Link to the badge

https://img.shields.io/bitbucket/pipelines/harisekhon/diagrams-as-code/master?logo=bitbucket&label=BitBucket%20CI

💡 Possible Solution

I thought this might be related to capitalization to match the repo name but that hasn't helped, it actually makes it worse in that it then doesn't find the repo

https://github.com/HariSekhon/Diagrams-as-Code

https://img.shields.io/bitbucket/pipelines/HariSekhon/Diagrams-as-Code/master?logo=bitbucket&label=BitBucket%20CI

so it looks like I need to go back to debugging what that Invalid Response Data is for the original badge lowercase format which appears to at least be finding something.

Any ideas how to debug what the actual response data is and why it is breaking?

[calebcartwright]

Any ideas how to debug what the actual response data is and why it is breaking?

Two common approaches:

1. Look at the Shields source code to determine the underlying API call we're making to the upstream provider (Bitbucket Cloud ostensibly in this case), then try to inspect that endpoint via your own calls/client (e.g. curl ...). It's possible the endpoint has changed their contract so that the response body structure no longer matches what we're expecting
2. Run Shields locally with TRACE_SERVICES=true environment variable set, and then make the same Bitbucket badge request to your local instance (instead of img.shields.io). That should, amongst various other log output content, show the response received from the API call

[chris48s]

If I request either of those badges, the response I get back from BitBucket is:

{
  values: [
    {
      state: {
        name: 'IN_PROGRESS',
        type: 'pipeline_state_in_progress',
        stage: { name: 'HALTED', type: 'pipeline_state_in_progress_halted' }
      }
    },
    {
      state: {
        name: 'IN_PROGRESS',
        type: 'pipeline_state_in_progress',
        stage: { name: 'HALTED', type: 'pipeline_state_in_progress_halted' }
      }
    }
  ]
}

and then the error we throw is "values[0].state.result" is required. "values[1].state.result" is required

Looks like we probably need some better error handling for the case where there is no result available.

[HariSekhon]

I think that's because my account is on the free plan which has run out of build minutes.

This must be quite a common occurrence and would probably be better handled with a grey HALTED status rather than throwing an error?

[chris48s]

Yeah I think that's a reasonable way to handle it. Would you be up for submitting a PR?

[reeceappling]

Put together a small PR that should resolve this. Let me know if any changes need to be made.