Better error handling when TechDocs can't find Docker

Expected Behavior

A friendly error message is presented to the user if/when Docker isn’t available to generate the docs tab on components.

Current Behavior

When I have Docker running, the sample “documented-component” correctly displays:

However, when I shut down Docker, I just see this:

Possible Solution

I couldn’t quite figure out how to trap this error, which I gather comes from the techdocs-backend, but doing some sort of return to the user using <Alert> of some type, a more standard error presentation than just raw spitting out the error path would be ideal, something to help guide the user. Maybe even adding a link to “setting up techdocs” in the doco here?

https://backstage.io/docs/features/techdocs/getting-started

Steps to Reproduce

Run locally, and,

1. Ensure no Docker daemon is running
2. Start up raw app latest off master branch
3. View the “documented-component” sample entity
4. Click docs tab
5. See error screen shot above

Context

Your Environment

• NodeJS Version (v12): v12.16.2
• Operating System and Version (e.g. Ubuntu 14.04): Windows 10 1909 WSL2 Ubuntu 18.04
• Browser Information: Microsoft Edge (Chrome)

[adamdmharvey]

This was fixed via https://github.com/backstage/backstage/pull/4314, as seen here:

Resulting backend error:

2021-02-09T02:20:12.611Z backstage error Failed to generate docs from /tmp/backstage-EsUwnM
into /tmp/techdocs-tmp-BcmhQJ with error This operation requires Docker.
Docker does not appear to be available. Docker.ping() failed with:
connect ECONNREFUSED /var/run/docker.sock type=errorHandler stack=Error:
Failed to generate docs from /tmp/backstage-EsUwnM into /tmp/techdocs-tmp-BcmhQJ
with error This operation requires Docker. Docker does not appear to be available.
Docker.ping() failed with: connect ECONNREFUSED /var/run/docker.sock

It would be nice to be able to even further trap THAT error, and generate a custom error object specifically for a Docker socket error as we talked about separately @OrkoHunter, so that a nuanced msg could be displayed to the user. But the ask here to improve the error handling is good for now so closing this bug to eliminate some noise.

[cmoulliard]

I think that might be worthy of a new issue, as the error is being elevated to the UI, but in your example and screen shot, it’s not possible to read and so that could/should be improved! it may be that the CSS for that heading doesn’t expect a very long string and so it’s writing over itself, but definitely looks like a bug.

Ok. will then create a new issue from my comment