Right now there is no differentiation between errors that are happening that are the fault of the software and the fault of the render build tool. For example, let’s say we have a node.js application that has a render build command. The build can fail if the command exits non zero; we also get a generic “Build failed :sadface:” message without any detail.
One of the problems with this is monitoring failed builds. A build can fail because it is broken but a build can also “fail” because it is pre-empted by another deployment. In those cases it is not a failure. It is simply cancelled.
If the script even provided some more specific logging or exit code logging that differentiated between a signal being received (intentional cancel / pre-empt) and a sub-command failure, that would be supremely useful.
We encountered something similar just today where we felt more context would be helpful.
Some of our deploys were failing to pass health check on start up due to a bad code change. This is fine - this is (part of) what health checks are for after all.
But we got a set of notifications to our Slack channel from the Render integration:
Server unhealthy for service-name-goes-here
Exited with status 1
…which, of course, caused us to wonder if our production service was struggling. But actually, it seems to have been from the deploying-but-not-yet-live service. And worse, in many of the cases, the deploy had been superceded by a new deploy, so the outcome was especially irrelevant to us.