I tried doing a deployment overnight. The solution consists of 8 files. The first 4 were “built” successfully (does a build simply consist of creating a clone?), but the 5th one failed.
I’ve run this deployment (with the same set of 8 files) successfully once before.
Is there some way I can find out what went wrong, so I can figure out how to prevent it from happening again?
Here’s the “detailed log” from the portal:
Phase
File
Message
Duration
scheduled
-
deployment scheduled
00:00.000
queued
-
Deployment queued
00:00.000
starting
-
Starting deployment: Deploy to PROD
00:00.000
starting
-
8 files
00:00.008
closing
-
Starting to close files
00:02.007
closing
-
Files closed successfully
00:18.208
building
-
Sending just in time build request to source server
00:18.217
building
-
Just in time build started on source server
00:19.207
building
-
Build running, completed 1 of 8 files
00:56.380
building
-
Build running, completed 2 of 8 files
01:04.560
building
-
Build running, completed 3 of 8 files
01:20.925
building
-
Build running, completed 4 of 8 files
02:10.071
building
-
Build server is unreachable: HTTP error: 502 - Bad Gateway: undefined
02:27.966
opening
-
Starting to open files
02:29.493
opening
-
Files opened successfully
02:39.558
post-deployment script
-
Post-deployment script not run since deployment failed
02:39.566
done
-
Deployment process failed. Original files are unmodified.
It looks like the deployment was triggered twice in a row. That shouldn’t have caused an issue. It should have just ignored the second attempt. But instead it just aborted the deployment. We’ll look into that.
It’s possible that a double click got sent through. We’ll also look at that.
But in the meantime, you may want to just try again.
Last night’s deployment worked without any problems. Thanks for the support you’ve provided to get me there.
In the previous two attempts, the glitch happened early on, before DMT. I was talking to a colleague of mine, and he reported a similar experience. In his case, he kicks off the deployment ad hoc and is able to monitor it during the initial phase, so it’s no big deal for him to manually retry it.
In my case, I have to schedule my deployment for overnight, because of the work hours that my client maintains, so it’s not convenient for me to retry it manually. Something to consider for you guys is to build in some retry logic if the deployment fails in those initial steps.
Thanks again for making this great tool available to the community.
If you’re getting the “Bad gateway” error, it usually means there is a network issue or that OttoFMS is not running properly on your source server. If you’re running low on disk space it could potentially cause OttoFMS to crash or fail to start, but that would only be if you’re completely out of space.
If you’re getting a build error that is not the Bad Gateway error, it is likely something else.