I’m come back to this problem again, having issues with Applying retention policies.
I am already connecting to VPNs in my scripts as the first step that runs before NuGet packages are uploaded. However, having the last step as ‘disconnect’ is a problem, because the connection closes before Retention Policies are run.
So far, I can’t find any way to force the script to run after the retention policy runs.
Could we either have a ‘Wait until retention policy finishes’ option for the last step similar to ‘Wait until NuGet packages downloaded’ found on the first step?
Alternatively, a manual step to trigger Retention policies would work too.
Another option to provide (as dave.griffiths mentioned) hooks for pre and post release scripts.
Seems to me this kind of set up could solve a lot of connectivity issues that are causing problems at the moment by letting folks script solutions for themselves.
I’ve just applied upgraded my Octopus Deploy to 2.5.4 and the last update that runs Retention policies after the last ‘package deployment’ step, rather than the final release step has solved my problem!
It it possible to get this to work in the current version using only scripts in OctopusDeploy? I’ve created 3 steps in my process:
- connect to VPN (powershell, works ok)
- deploypackage and install windows service
- disconnect VPN
But I can’t start my deploy/pormote the build because the machines don’t respond yet… “Warning - there are no enabled machines in roles specified”. Is it possible to do this automatically somehow?
I also tried to login to OctoDeploy-server with remote desktop, manually connect to VPN (now my remote-desktop connection with OctoDeploy-server is lost…) and then promote the build, but this don’t work because OctoDeploy don’t respond anymore in my local network after it has connected to remote location with VPN…
If someone found a solution to this, how did you do it?
When you get the “Warning - there are no enabled machines in roles specified” error, could you look at your environments page? Are the machines in a red/“Failed” state, or are they disabled?
yes, status is “red” in environment
Not connected. The machine has not completed a post-configuration handshake, so communication is not yet established.
Here is the script I’m planning to execute from the Octopus-server:
nclauncher -url https://ssl.domain.com -u admin -p 12345 -r Users
C:\OctopusTools.18.104.22.168\Octo.exe promote-release --project=“MyWindowsService” --from=“Production MyCompany” --to=“Production PartnerCompany” --server=http://localhost:8099 --apiKey=API-XXX -user=administrator -pass=123 --waitfordeployment --progress
But this fails since Octopus deploy have never communicated successfully with server in partner environment, and skips all steps in the deploy(?). When I open the VPN-connection on the OctopusDeploy-server, I loose my remote desktop connection to the server, and cannot do this manually.
I guess another solution is to install a completely new OctopusDeploy-instance at our partner company network, but I would really love to have both environments in the same GUI. Do you have any suggestions on how I can accomplish this?
I am very sorry we did not get back to you about this, it was buried in a spam folder.
Did you find a solution to this problem?
Well, I didn’t get it to work using VPN, and I still think this could be a nice feature in OctopusDeploy (?)
We ended up exposing the remote server with a public ip on OctopusDeploy’s port, and adding firewall-rules so that only OctopusDeploy-server and the remote server is allowed to communicate on this port. This works fine, but you need a public ip and a bit of firewall setup.
I guess an even better solution in our case would be a polling tentacle, I’ll try that the next time