PostDeploy.ps1 is still running 2x; using v2.3.4


Since upgrading to Octopus 2.x, we are having issues with Pre or Post deploy scripts running 2x. Both the PreDeploy.ps1 and PostDeploy.ps1 are set as follows:

‘Build Action’ = None
‘Copy to Output Directory’ = Copy always

We never before had these issues. We have played with the above two settings, but cannot get the same behavior as 1.6.x.

The deployment issues are currently with Windows Service projects that are fully installed via custom PostDeploy.ps1 scripts.

Please advise.


Additional SS.

Hi Jesse,

Thanks for all the info. Are you using the new (3.x) version of Octopack?

If its possible can you please open the NuGet package (using a zip extractor or Package Explorer) and let us know if the file appears in more than one location?

Unfortunately, the verbose log doesn’t show the script file’s full path; I’ve just made a local change to make sure we record it in 2.4 and make this a bit easier to diagnose.


Hi Nick,

Both Pre & Post are in the package 1x each, directly in the root. The entire package is flat except the _rels and package directories.

Our projects are currently using Octopack 3.0.20.

Octopus Server is currently:

Thanks Jesse; I’ve created an issue here to track this one:

Inspecting the code, we do use some lazy evaluation while searching for script files; while I can’t see exactly how that might cause this result, writing to the folder while incrementally reading its contents seems like a plausible theory.

I’ve fixed that and made the change to improve logging in the 2.4 codebase. We’re still finalizing that version but should have a -pre out very soon. How badly is this shaking things up? I will try to come up with other workarounds if needed…


It’s not crazy urgent atm. I have beefed up the PostDeploy.ps1 to handle a possible second pass so all is well. Look forward to solving this one.

Hi Jesse,

We’ve now shipped 2.4.1 as a preview, with several changes aimed at eliminating this or at least improving debugging.

I know an upgrade might not be on the cards in the immediate future, but if you do replicate it on 2.4.1 (and I hope you won’t :)) then we should be able to spot the issue in the logs.


Awesome, thanks Nick. I will install this today and give it a whirl.

Nick, I installed the 2.4.1 preview. I haven’t pushed out any releases yet except one, and what we found is possibly disturbing. The Octopus user we use from TeamCity for pushing over packages no longer works with the same API key. We added a new API key to an existing user and that worked. I was hoping not to have to update so much in TeamCity. Any idea why the previous API keys no longer work after this last minor update? I see 2.4.2 is out now also.

We have also noticed some issues with the Steps/Process migrations with the email steps. Many of ours have lost the CC, BCC fields and only maintained the TO fields. Maybe these are 1.6 migration artifacts to 2.x.

Thanks for all the work.

HI Jesse - no, those issues would be news to me… 2.4.2 went out because of some variable evaluation issues and a missing migration for LibraryVariableSets, shouldn’t be anything relating to API keys or settings.

If you have a chance to raise a separate ticket with anything you can nail down we’ll dig in (OctopusServer.txt logs etc. might help). Hoping we’ve cracked the 2x script one at least!


PostDeploy.ps1 is now executing properly again, only once and no issues with PreDeploy.ps1 either. This seems to be working properly now. I’ll post again if we notice any other issues.

As far as the API keys not working. I’ll start a new issue with that since it’s separate. I didn’t realize I was replying to support group emails previously.