[Bug Report]: Tags - existing tags get deleted on subscription and rg level

[ntaheij]

Describe the bug

Currently, the Resources - Tags test deployment removes all tags after testing on that specific resource, i.e. subscriptions and resource groups.

To reproduce

1. Add tags to a subscription.
2. Deploy the Resources - Tags CI tests, to above subscription.
3. See results in Azure portal.

Before:

After:

Expected After:

Code snippet

No response

Relevant log output

No response

[eriqua]

Ref discussion in #3280

[AlexanderSehr]

Hey @ntaheij this is the expected behavior as tags (very much like subnets, route table rules, etc.) are essentially always overwritten.
That being said - for this module, we did implement a parameter onlyUpdate that should achieve the behavior you desired. Did you give that a go?

[AlexanderSehr]

I just ran the following test

Test 1

Location: PS C:\dev\ip\Azure-ResourceModules\ResourceModules> New-AzDeployment -ResourceGroupName 'artifacts-rg' -TemplateFile 'C:\dev\ip\Azure-ResourceModules\ResourceModules\modules\resources\tags\main.bicep' -Tags @{ a = 'a'; b = 'b' } -verbose -Location 'WestEurope'
VERBOSE: Using Bicep v0.18.4
VERBOSE: 19:12:23 - Template is valid.
VERBOSE: 19:12:24 - Create template deployment 'main'
VERBOSE: 19:12:24 - Checking deployment status in 5 seconds
VERBOSE: 19:12:29 - Resource Microsoft.Resources/deployments 'main-Tags-RG' provisioning status is running
VERBOSE: 19:12:29 - Resource Microsoft.Resources/tags 'default' provisioning status is succeeded
VERBOSE: 19:12:29 - Resource Microsoft.Resources/deployments 'pid-47ed15a6-730a-4827-bcb4-0fd963ffbd82-537rttv2f5xy4' provisioning status is running
VERBOSE: 19:12:29 - Checking deployment status in 13 seconds
VERBOSE: 19:12:43 - Resource Microsoft.Resources/deployments 'main-Tags-RG' provisioning status is succeeded
VERBOSE: 19:12:43 - Resource Microsoft.Resources/deployments 'main-Tags-RG' provisioning status is succeeded
VERBOSE: 19:12:43 - Resource Microsoft.Resources/deployments 'pid-47ed15a6-730a-4827-bcb4-0fd963ffbd82-537rttv2f5xy4' provisioning status is succeeded

Id                      : /subscriptions/***/providers/Microsoft.Resources/deployments/main
DeploymentName          : main
Location                : westeurope
ProvisioningState       : Succeeded
Timestamp               : 06.07.2023 17:12:45
Mode                    : Incremental
TemplateLink            : 
Parameters              : 
                          Name                      Type                       Value
                          ========================  =========================  ==========
                          tags                      Object                     {"a":"a","b":"b"}
                          onlyUpdate                Bool                       false
                          resourceGroupName         String                     "artifacts-rg"
                          subscriptionId            String                     "/subscriptions/***"
                          location                  String                     "WestEurope"
                          enableDefaultTelemetry    Bool                       true

Outputs                 : 
                          Name             Type                       Value
                          ===============  =========================  ==========
                          name             String                     "default"
                          tags             Object                     {"a":"a","b":"b"}
                          resourceId       String                     "/subscriptions/***/resourceGroups/artifacts-rg/providers/Microsoft.Resources/tags/default"

DeploymentDebugLogLevel : 

Test 2

PS C:\dev\ip\Azure-ResourceModules\ResourceModules> New-AzDeployment -ResourceGroupName 'artifacts-rg' -TemplateFile 'C:\dev\ip\Azure-ResourceModules\ResourceModules\modules\resources\tags\main.bicep' -Tags @{ c = 'c' } -verbose -Location 'WestEurope' -onlyUpdate $true
VERBOSE: Using Bicep v0.18.4
VERBOSE: 19:15:27 - Template is valid.
VERBOSE: 19:15:28 - Create template deployment 'main'
VERBOSE: 19:15:28 - Checking deployment status in 5 seconds
VERBOSE: 19:15:34 - Resource Microsoft.Resources/deployments 'main-Tags-RG' provisioning status is running
VERBOSE: 19:15:34 - Resource Microsoft.Resources/deployments 'main-Tags-RG-ReadTags' provisioning status is running
VERBOSE: 19:15:34 - Resource Microsoft.Resources/tags 'default' provisioning status is succeeded
VERBOSE: 19:15:34 - Resource Microsoft.Resources/deployments 'pid-47ed15a6-730a-4827-bcb4-0fd963ffbd82-537rttv2f5xy4' provisioning status is running
VERBOSE: 19:15:34 - Checking deployment status in 12 seconds
VERBOSE: 19:15:46 - Resource Microsoft.Resources/deployments 'pid-47ed15a6-730a-4827-bcb4-0fd963ffbd82-537rttv2f5xy4' provisioning status is succeeded
VERBOSE: 19:15:46 - Checking deployment status in 15 seconds
VERBOSE: 19:16:02 - Resource Microsoft.Resources/deployments 'main-Tags-RG' provisioning status is succeeded
VERBOSE: 19:16:02 - Resource Microsoft.Resources/tags 'default' provisioning status is succeeded
VERBOSE: 19:16:02 - Resource Microsoft.Resources/deployments 'main-Tags-RG-ReadTags' provisioning status is succeeded
VERBOSE: 19:16:02 - Resource Microsoft.Resources/deployments 'main-Tags-RG-ReadTags' provisioning status is succeeded
VERBOSE: 19:16:02 - Resource Microsoft.Resources/deployments 'main-Tags-RG' provisioning status is succeeded

Id                      : /subscriptions/***/providers/Microsoft.Resources/deployments/main
DeploymentName          : main
Location                : westeurope
ProvisioningState       : Succeeded
Timestamp               : 06.07.2023 17:16:03
Mode                    : Incremental
TemplateLink            : 
Parameters              : 
                          Name                      Type                       Value
                          ========================  =========================  ==========
                          tags                      Object                     {"c":"c"}
                          onlyUpdate                Bool                       true
                          resourceGroupName         String                     "artifacts-rg"
                          subscriptionId            String                     "/subscriptions/***"
                          location                  String                     "WestEurope"
                          enableDefaultTelemetry    Bool                       true

Outputs                 : 
                          Name             Type                       Value
                          ===============  =========================  ==========
                          name             String                     "default"
                          tags             Object                     {"a":"a","b":"b","c":"c"}
                          resourceId       String                     "/subscriptions/***/resourceGroups/artifacts-rg/providers/Microsoft.Resources/tags/default"

DeploymentDebugLogLevel : 

Could it be an issue with a specific coke? Did you deploy the child-modules or the Tags module in root?

[ntaheij]

Hey @ntaheij this is the expected behavior as tags (very much like subnets, route table rules, etc.) are essentially always overwritten.
That being said - for this module, we did implement a parameter onlyUpdate that should achieve the behavior you desired. Did you give that a go?

Yes, I have tried onlyUpdate. But sadly when using the CI environment automatic deletion function, it deletes all tags in the entire subscription that is used for the test changes.

[AlexanderSehr]

Ah sorry that's my bad - I somehow didn't realize this is a CI-related issue.

Ok yes - then this makes sense. The removal logic will likely try to remove the tags it deployed but as it 'tags' are not individual entities but one object it simply overwrites/remove the entire block.

The only workaround that would come to mind right now would be to disabled the subscription-level test. Either by messing with the test's name (as the CI looks for a main.test.bicep) or by removing the subscription-level test completly.

It's unfortunately notthing more than a workaround. To really 'solve' it, I would think the removal logic would need have a case handling for Microsoft.Resource/tags as we have it for other resources.

@eriqua, would you agree?

[ntaheij]

Ah sorry that's my bad - I somehow didn't realize this is a CI-related issue.

Ok yes - then this makes sense. The removal logic will likely try to remove the tags it deployed but as it 'tags' are not individual entities but one object it simply overwrites/remove the entire block.

The only workaround that would come to mind right now would be to disabled the subscription-level test. Either by messing with the test's name (as the CI looks for a main.test.bicep) or by removing the subscription-level test completly.

It's unfortunately notthing more than a workaround. To really 'solve' it, I would think the removal logic would need have a case handling for Microsoft.Resource/tags as we have it for other resources.

@eriqua, would you agree?

No worries at all! That is the fix my PR (#3280) was aiming at. It isn't optimal, as it used hard-coded variables. But I think it's a step in the right direction :)

[AlexanderSehr]

I agree. I wonder though if the solution should be more robust in that instead of using hardcoded values we could fetch the tags from the bicep template. Then again, with everything else happening in the background in terms of publishing to the Public Bicep Registry it's at least debatable if we should implement this now.
This renders your PR as a good compromise.

[ntaheij]

I agree. I wonder though if the solution should be more robust in that instead of using hardcoded values we could fetch the tags from the bicep template. Then again, with everything else happening in the background in terms of publishing to the Public Bicep Registry it's at least debatable if we should implement this now.
This renders your PR as a good compromise.

I do agree that hard-coded variables are not the way to go, yet so far I don't see any solution about it except i.e. configurable variables.

[AlexanderSehr]

I'll go ahead an archive this issue given that the module was not migrated to AVM