Option to merge tags on deploy

[o-l-a-v]

(I understand that this might not be up to Bicep to solve.)

Is your feature request related to a problem? Please describe.

ARM deployments currently replaces current tags. Some tags might be set manually or by other automation. Which means:

1. Information might be lost.
2. What-If lists a lot more resources are to be modified, just because it will remove tags not defined in Bicep.

The ARM API supports different operations against tags, as shown with the Update-AzTag PowerShell command which supports ( https://learn.microsoft.com/en-us/powershell/module/az.resources/update-aztag?view=azps-12.4.0#-operation ):

• Merge: Set tags defined with the request, don't touch the existing ones unless they are in conflict.
• Replace: The same as what ARM deploy does.
• Delete: Remove tags.

Describe the solution you'd like

The ability to set tag deployment behavior on different scopes. Sometimes it makes sense to have it for the whole deployment. Other times maybe override on a per resource basis.

[alex-frankel]

@o-l-a-v - can you add a little more detail to this one? How are you declaring tags in your bicep file today and does the behavior vary between different resource types? Can you also share what you would want the bicep code to look if we were to address this issue?

As you mention, tags are not owned by our team, but we'd be happy to get the conversation started once we have those details.

[o-l-a-v]

I'm declaring tags in Bicep like everyone else, adding it as a property to whatever resource I'm creating. I also know how to merge two or more objects to use some tags for all resources but differentiate other tags etc.

• https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-functions-object#union

The problem is when tags are added outside of Bicep. It could be manually / humans / clickops, it could be with other automation tools. For instance I have a PowerShell script that sets created date retrieved from the ARM API, because this value can't be fetched by Bicep at deploy time, at least not that I know of.

Barebone PowerShell example to get created date from ARM API

# Import modules
Import-Module -Name 'Az.Accounts', 'Az.ResourceGraph'

# Get all subscriptions
$AzSubscriptions = [array](Get-AzSubscription)

# Add resources and resource groups with CreatedTime and ChangedTime from the ARM API
foreach ($AzSubscription in $AzSubscriptions) {
    $null = Add-Member -InputObject $AzSubscription
    $null = Add-Member -InputObject $AzSubscription -MemberType 'NoteProperty' -Force -Name 'Resources' -Value (
        [PSCustomObject[]](
            $(
                [string[]](
                    'resources',
                    'resourceGroups'
                )
            ).ForEach{
                (
                    ConvertFrom-Json -InputObject (
                        (
                            Invoke-AzRestMethod -Method 'GET' -Path ('/subscriptions/{0}/{1}?$expand=createdTime,changedTime&api-version=2021-04-01' -f $AzSubscription.'Id', $_)
                        ).'Content'
                    )
                ).'value' | Select-Object -Property 'Id','CreatedTime','ChangedTime'
            } | Sort-Object -Property 'Id'
        )
    )
}

The problem then becomes that next time Bicep deploys, tags not defined in Bicep get's nuked.

The ARM API supports merging tags as already mentioned. If ARM / Bicep deploy could utilize that somehow, my expected behavior would be that deploy would overwrite all existing tags with conflicting name, but not touch tags not defined in Bicep.

I don't know if this is even possible, how it could be done, and what the syntax would be. Maybe like we have targetScope we could set tagWriteOperation with default Replace but optional Merge? 🤔

[alex-frankel]

Got it. I don't know the latest on how tags are handled. At one point, tags were all handled separately by each Resource Provider, but I know there are/were efforts to centralize tag management. I'm going to transfer this to bicep-types-az and will make the right stakeholders aware of this. That being said, I wouldn't expect changes to this situation quickly.

[alex-frankel]

@jennyhunter-msft can you take a look at this one? I don't recall the latest developments to central Tag management, but I know this is something that has come up before.