Manual test results using userassignedidentity.fsx by modifying the add_to_group line

</details>

Is there some way to assign these groups with an ARM deployment?

Not that I could find. There is also this question which implies it's not

possible:

https://docs.microsoft.com/en-us/answers/questions/214227/can-we-add-users-group-azure-ad-using-arm-template.html

We shouldn't put it in the same builder, then. There is no way to tell that this isn't going to be in the resulting template.

Maybe this should be a CLI wrapper only and go in the AzHelpers module. What do you think @isaacabraham? Most of the CLI wrappers are specifically for ARM deployments and this is starting to become more general purpose Azure CLI, so I'm not sure where it goes.

I thought the whole point of PostDeploy actions was to do things exactly like this from the builder? Similar to webapp's zip_deploy or storageAccount's use_static_website. Is the plan not to control PostDeploy tasks on the builders anymore?

Or is the concern the location of the logic rather than the addition of an operator in the builder?

Those two are rolling out your application code to those resources.

I'm in two minds here. I'm not specifically opposed to this as a post-deploy action personally - it's not the end of the world if some bits go into the CLI as well as ARM - as long as everything that can go into ARM, does. Then again, for the AD side of things, we already have some CLI helpers - could this not be one of them?

I'm not sure I have the answer here. I think maybe it's about the declarative nature of "I want to create this identity, it's part of these groups" as a declarative statement - in which case this might be fine. This is the approach we took for the upload app stuff.

It may make sense to have some CLI wrappers around AD group assignments, but I don't think it's a good idea to tie them to user assigned identities. You have to have much greater permissions to manage AD group assignments than to simply create an identity for a resource, so this would be a deployment that would partially fail in a lot of cases. Also you can't really even do them through ARM deployments, and this limitation isn't really clear to a user that's creating the resource.

I was hoping to achieve the declarative statement as mentioned by isaac but I do see that this would be confusing for users who only use Farmer as an ARM generator (rather than a deployment tool).
If we were to make this an Az Helper, I was wondering if adding a keyword such as post_deploy might be acceptable to allow us to maintain this declarative nature without the confusion? Maybe something like the following?

userAssignedIdentity {
    name "my-test-identity"
    post_deploy (AzHelpers.addIdentityToActiveDirectoryGroup "my-apps")
}

I'm assuming that post_deploy will take a UserAssignedIdentityConfig -> unit so that the called function would still have access to the configured identity object.

Hi @TheRSP - can we look at getting the conflicts dealt with? Thanks