We’re not sure it’s a bug, but simply a side-effect of how Project Triggers work in Octopus.
When a Project Trigger causes a deployment to run, it re-queues the existing deployment task. So Octopus is simply re-running the original deployment against the new machines that become available. This guarantees the exact same deployment process and variables are run against any new machines, and allows all machines to be included in the one deployment’s task log.
The deployment itself was still created by the original user. These
CreatedBy variables only get created once, when the release is created, which is why these variables won’t get updated when Project Triggers cause the deployment to be re-queued.
Unfortunately, from the variables alone, I don’t believe there’s a way to determine if the deployment was being re-queued by the system vs by a user.
You could consider adding a uservoice suggestion describing your situation and what variables would be of benefit in your case. Maybe a
QueuedBy variable would be of use here? If your suggestion gets enough community support/votes, we will consider adding it as a feature in a future version of Octopus.