Hi Octopus, we are facing the error similar to this post: Step is succeeding with warning instead of failing after upgrade to 3.5.1, in which we see an error message saying that Bootstrap.Deploy.ps1 is trying to execute Deploy.ps1 but it fails with some error message, however, we have no idea at all where this Bootstrap.Deploy.ps1 is coming from? Is it auto-generated by Octopus whenever it sees a ps scripts in the deployment package?

Hi @tatsean1977,

Thanks for getting in touch, and welcome! You’re essentially correct, and to quote our custom scripts doc page:

The Tentacle agent or SSH session invokes the open-source Calamari project to bootstrap your script and provide access to variables and helper functions. You can see how your scripts are bootstrapped in the Calamari source code.

In regards to troubleshooting the error you’re seeing, would you be willing to send over a resulting task log of an instance where you’ve hit this issue? Seeing the details of the error, the context around it, and other logged details within should help us narrow down what might be causing this.

Feel free to email the log file to for privacy, or I can provide an alternative upload link if you prefer. :slight_smile:

I look forward to hearing back!

Best regards,


Hi Kenny, sure, here is additional info:

The error is: The term xxxxxxx\Deploy.ps1 is not recognized as the name of the cmdlet, function … At yyyyyyyy\Bootstrap.Deploy.ps1:2443 … It also shows CategoryInfo : ObjectNotFound … FullyQualifiedErrorId: CommandNotFoundException

Before this error message, it shows “Copied 14 files” and in the nuget package, we are quite sure that we have 14 files including the Deploy.ps1, but base on the error, somehow, it can’t find the “Deploy.ps1”?

However, when we were asking Release team to run one more time for the deployment, it works. And there is one server, we have to run the same deployment 3 times, only then it works.

Hi @tatsean1977,

Thanks for following up! I suppose that’s somewhat good news that it eventually works, but certainly that’s inconvenient and odd.

What I’d really like to see to try to piece this puzzle together are two task logs - one from a working deployment, and one from a failure. Comparing the two side by side, along with seeing other details like the type of step being run, where precisely in the process it’s erroring, the Octopus version, etc. will allow us to investigate in depth. Hopefully that will help us narrow down the cause, or to reproduce a potential bug.

Best regards,


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.