Acquire packages step running too soon


I have a deployment that is a mixture of steps running on the Octopus server and on target machines via tentacles.

The first few steps are for environment warming, and at that point the target machines do not exist. The steps ran against them are much later in the deployment process, after the steps to deploy them via ARM templates (Azure).

Unfortunately the acquire packages step is running at the beginning of the release on the Octopus server, and the three target VMs, at which point connectivity to them can’t be established and the build is failing. None of the steps are configured to run in parallel, and none are configured to wait until packages have been downloaded (plus the Powershell steps against the target machine don’t have the option). The VM scripts are configured to come from a package, not directly entered into the scripting pane of the step. Is that the problem?

Is it possible to set the acquire packages to run multiple times during the release (once on the Octopus server, and later against the VMs)?

Hi Stewart,

Thanks for getting in touch.

If you’re dealing with transient environments, you could change the machine connectivity settings so that your deployment skips machines if they are (or become) unavailable during a deployment. This should stop your “acquire packages step” failing for those machines.

Once your ARM template has run and you know your VMs should now exist (and they’re registered as Tentacles with Octopus), you will need to run a Health Check step to include the machines in your deployment. You could set the health check step’s options to: “Perform a connection-only test” and “Include new deployment targets in the deployment”.

Any steps after this Health Check step, that target your new VMs by role, will then see them as valid Deployment Targets and be able to run.

Would this potentially solve your issue?

If not, could you please confirm which version of Octopus you are running? And could you please attach a full task log from one of your failed deployments and we’ll see what we can find.