Hi @ritvij05,
Thanks for getting in touch!
I believe one of your colleagues may have raised a similar question on Friday: Error from Octopus Server (HTTP 503 ServiceUnavailable)
As the error seems to be coming from the Octopus Server I’m wondering if there could be a load issue caused by triggering a large number of deployments at the same time causing the server to become unavailable or the service to restart.
If you check the Octopus server logs (default location C:\Octopus\Logs) for the times and dates that your build pipeline has failed do you see any errors appearing?
If you’d like us to take a look through those logs feel free to either private message them to me here or email them through to support@octopus.com
The odd part here is that the Octopus UI makes full use of the REST API. So, when you trigger these deployments from within Octopus, the same API calls will be made as the ones that ADO is making.
When this pipeline runs, am I correct that some of the tenant deployments are being successfully initiated before the failure occurs and you are only deploying the remaining tenants from within Octopus?
If so, would it be possible to perform a test deployment from within Octopus that includes all of these tenants? I’d like to see whether the same error occurs when this is run within the UI.
Regarding your question about a retry mechanism for the pending tenants when it fails. With the current configuration the only option I see is what you’ve been doing. Which is to run the remainder of the tenant deployments within Octopus.
One alternative option would be to make use of the ADO Release Pipeline feature rather than the standard pipeline for creating the release and running these deployments.
The benefit of this is that in the event of any failures you can re-trigger any failed deployments from within ADO.
e.g.
I appreciate that this would be a significant change though and would take some time to implement.
Regards,
Paul