Hi guys,
I have a simple project with two steps within it. The first step runs a powershell script targeted at a role named ‘environment-host’, which simply executes
Write-Verbose “Hello World”
Against a target machine with that role in an environment, so that the project can register a deployment for a given release for that environment, so that triggers can then work.
The second step is a simple nuget package deployment to an IIS website.
The behaviour I am seeing is that if I do a deployment and target a specific machine (the ‘environment-host’ machine), that deployment executes the first step and skips the second, and I will have a successful deployment of this release of the project registered in that environment.
But immediately after it executes the project trigger attached to the project seems to fire. The trigger is set up as so:
New deployment target becomes available for QA with role web-server
The final piece to this is that I have four ‘dead’ machines with a role of web-server in the environment that have been torn down via cloud formation, but Octopus has not yet cleaned up with their machine policies, which is set to clean them up if they don’t pass a healthcheck within an hour.
Let me know if you need any more info.
Cheers,
Andrew.
ServerTasks-131.log.txt (6 KB)
Here is a screenshot of the task pane post-deployment
Hi Andrew,
Thanks for getting in touch.
It looks like our trigger logic is not differentiating between new and existing deployment targets so your existing targets are getting scooped up in the auto deployment. Will fix ASAP.
Were the ‘dead’ machines eventually cleaned up? It’s not clear if that is problem as well, or if there recently became ‘dead’ and were just pending clean up.
We’re also working on a mechanism to “register a release for an environment” so you don’t have to go through the dance of creating a deployment for the sake of getting auto-deploys to trigger.
Cheers,
Shane
Howdy Shane,
A quick question - you say the trigger logic is not differentiating. I am surprised I am getting a trigger firing in the first place though - I’m just executing a deployment (‘push’), the machines are not arriving (to trigger a ‘pull’), so why is the trigger firing after the ‘push’ deployment in the first place? I’m not sure if this is something I’m fundamentally not understanding about triggers, or a bug in the implementation.
My expectation is - I say ‘deploy project y to machine x’, deployment executes for project y and steps for roles assigned to machine x are executed. And that is the end of it.
Reality is - the above happens, but then a project trigger fires. This seems less about differentiating machines, and more about the trigger firing after a deployment in the first place.
If you could enlighten me on the above, that would be great 
Yes, the dead machines do get cleaned up as expected - they had recently been torn down, and had not yet hit the cleanup window kudos on that feature, it saves a lot of stuffing around with Lambdas and the like.
The ‘register a release for an environment / tenant’ will also be fantastic, as that is one of the last ‘yuck’ parts of the orchestration left.
Hi Andrew,
There is an implementation bug, but I’ll try to explain why it is happening.
Imagine if you have a deployment in progress and infrastructure starts coming online that should be the target of auto-deployment. We don’t kick off an auto-deployment while the deployment is in progress because we’re unsure if the deployment in progress is going to succeed.
Once the deployment finishes we check if there are any machines that should be deployed to. In the case you are seeing we are erroneously finding four machines that are missing the release you just deployed. What we should be doing is checking if there any machines missing the release that satisfy the trigger criteria (ie: are machines that have been created since the deployment started).
Our intention is that a trigger will fire immediately after a deployment when triggering events have occurred while the deployment is in progress. So if you added 5 machines during the deployment, they would be immediately deployed to once the deployment finished. Does that seem reasonable to you?
Hope this helps explain what you are seeing and interested in your feedback.
Cheers,
Shane
Ah perfect, that makes a lot more sense now
Would you still continue with this behavior one you have ‘approved releases’ built in? I.e. if I have a deployment of a project in progress, but there is already an approved release for that project for an environment or tenant, and machines came online during the deployment of the project that matched a trigger definition, I’d prefer it just to deploy the approved release immediately, rather than worry about the result of the probably unrelated deployment.
