Hello!

So, continuing the saga of deploying the ARM templates of ADFs that are generated by the npm package made avilable by Microsoft, I came across something that I was not aware of, and honestly I really should have been. Although runtimestate can be included in an ARM Template to deploy a Trigger, the runtimestate on the deployed ADF will not be altered to match what is in the ARM template.

Whilst this might seem confusing, it does make sense as it is not included in the triggers api. It will be added in the properties element of the generated ARM template, but it will be ignored. Apparently it is a read-only property that can only be alterdd on the server side but not the client side.

This is where the prepostdeployscript.ps1 comes into play: what this does pre-deploy is find any triggers in the ARM Template that are supposed to be in the started state and checks the payload of the trigger to be deployed against what is currently deployed on the ADF. If there is a difference between these two then the trigger will be stopped and altered as part of the ARM Template deploy (remember runtimestate will be ignored). Post-deploy the script will then search through the ARM Template for the triggers whose runtimestate is set as started and start them if they are stopped.

This does assume that the runtimestate stored in the ARM template (and therefore the ADF source control) is correct, and that there is no issue with them being in a started state in all environments. In my experience this is not the case, and so trigger runtime state management continues to be fun…