We are trying to have an automatic deployment using triggers, However, we encountered a bit of a bump. Although the deployment is done (successful with Warnings) on the Initial deployment targets when we register an additional target the deployment trigger works well but includes the other targets as well (the ones that were already completed on). We also have the re-deploy option in triggers unticked but still, the targets are included. Just to also mention, before this event, we had a failed attempt of this release (Timeline: Release Successfully including Targets 1,2,3,4 - Release canceled including Target 5 - Release Triggered on Targets 1,2,3,4,5 Although title specifies otherwise). Screenshots are attached for some clarifications.
Any idea why is the deployment triggering on all the machines?
Also, we were wondering, if is it possible that no matter what the deployment status is, some steps will still run on the deployment targets (like right now but with selected steps) ?
I’m just jumping in for Shawn quickly as I attempted to reproduce this seemingly incorrect behavior with no luck. If you’re running a self-hosted instance of Octopus, could you also send through your auto deploy logs (in the web portal under Configuration > Diagnostics > Auto Deploy Logs) along with the version you’re running? If you’re using cloud, would you be willing to grant us permission to have a look as a support user and let us know your instance URL?
I look forward to hearing back and getting to the bottom of this one!
I am using v2021.2 (Build 7650) - Self-hosted. Unfortunately all I got in the log is the attached. both when I choose download All - Info and All - Verbose
We just Re-deployed everything and had same reaction, but this time I have something in the Diagnostic Logs >> ProcessAutoDeployments.log (3).txt (23.3 KB)
I can see three separate events in this log file. The first event included machines H01, MT, and MTB01, however deployed only to H01 as the other two were not found to be eligible.
The second event included machines MT, MTB01, and A01 to which all three were determined eligible.
The third event included only T01 and was found eligible.
The event filters you have configured includes: Machine enabled, Machine found healthy, and Machine found to have warnings. Do you know if any of those machines had status changes which would match any of that criteria?
I am actually checking the health within the process itself (as a step), will this trigger the process for them? Also, Shouldn’t it check anyway if the deployment is on the machine and skip if done since I did not mark to “re-deploy” within the triggers?
I’ll test by removing the machine enabled from the filter, see how it goes.
You’re correct, it should not deploy to a machine that already has that release. Having the health check within the deployment process shouldn’t include additional targets during that run. However, if the machine had a status change to one of your included status for the trigger, that could potentially trigger the deployment and consider that machine. Does that make sense?
Just to let you know will be testing this later as we hit another rock in our own config. however, once you mentioned the health check I did some more analysis and it might be some of these steps having these options that are forcing the deployment:
Although they are not new Deployment targets, maybe there is a window on what is classified as “new” machines as these are hours old normally in our tests and of course, also change the trigger options. Will post back the updates after we do such testing.
