Often, with a failed deploy (or even a successful one), you will see a log line similar to this:
1:23:45 PM: Shutting down logging, 67 messages pending
What does this mean? Well, it means that the build process completed before all log messages were uploaded to our logging service. This is not something you need to worry about or work to address unless it is impacting your ability to debug a failing build.
When debugging a build, this tends to be a big problem because troubleshooting a failed deploy begins with examining those logs. If the error itself is missing, that is quite an obstacle.
But wait! There is a workaround for this. And we’re working on a longer term solution of upgrading the log system, so the workaround is only required to help you troubleshoot for now.
Before we begin, though, a disclaimer:
- Note: These are temporary settings for diagnostics only. You must remove them after getting full logs as they force all builds to fail ! (Even if the build would otherwise succeed.)
Okay, so moving on to that workaround. It is done by using two commands:
The sleep command causes the system to wait for a specified number of seconds. But there is a problem: that sleep will also return an exit code of zero (0).
Why is a zero exit code a problem? Well, the exit code is what tells the build system if the build was a success or not. A zero exit code from the last command run is an indication of a success.
So, if we add a sleep command to wait for the logs to finish uploading we have a new problem. The build system will then attempt to deploy the failing build (since it looks successful - because it ended with a zero exit code).
Now the false command comes to our rescue. It will return a non-zero exit code (normally 1). This will force the build to fail.
So for example, if your build command is this:
npm run build
Then the new command would be:
npm run build ; sleep 120 ; false
In the example above sleep 120 means wait 120 seconds (two minutes). This is usually enough time to see the full deploy logs; if you’re missing many hundreds of lines (>500) you may want to extend it to a higher number, maybe 300 or more. The semi-colon ( is used to separate the commands so each will run independent of the exit code from the prior command, which is ONLY desirable in this one case. Usually you should use && to chain build commands so that only if EACH command succeeds, will the next one run, ensuring that any failure will cause your build to be marked as failed.
As a reminder, these temporary settings will always cause every build to fail . So, please remove the settings once you have a full log to debug because all future builds will fail until these settings are removed.