The recommendation is to add logic into the webhook service. The unfortunate answer we don’t plan on adding functionality like that into Octopus Deploy. There are so many different business rules, there is no way we could write a feature that satisfies all of them. For example, one person wants to filter out any events which are auto deployments. Another wants to be notified if an auto-deployment occurs 2 or more days after the deployment.
With that out of the way, let’s dive into what is happening and what the webhook service can potentially query to aide in the filtering. To start with, an auto-scaling trigger will reuse the last successful deployment. The deployment screen will look like this:
Now if we look over to the right of the screen we can see the task history. Each auto-scaling deployment has an entry.
If we look closer at the results of the messages of the API call we can see some interesting tidbits.
If we scroll down to the very start of the task history we can see what it looked like when a human triggered the deployment.
The endpoint that is being hit in this example is: http://localhost:82/api/events?regardingAny=ServerTasks-3156&skip=0&take=10000. That API returns events in desc order of when it occurred.
In the service, you will need to look at the related documents for the event. That will give you the ServerTasks Id to use in the API call.
With that, you will need to loop until you find the Deployment Queued event and look at who triggered it. If it was “system”, then chances are it was an auto-deployment.