This message was deleted.

Ah I recently change the ignore changes logic to try and fix an odd case where arrays were getting zero'd out rather than ignored. That may have changed this as well. But I think the error is probably correct, I don't see any property tag_created_date (or tagCreatedDate) in azure-native.

Thanks @echoing-dinner-19531. tag_created_date is a custom tag we set on our resources

Ah right, "ignoreChanges" won't understand that. The tags property is an array and ignore changes only knows how to ignore specific indices in an array. Not how to ignore a specific value in it.

We are using

StackOptions

to ignore changes to our custom tag like so

public StackOptions GetStackOptions()
    {
        return new StackOptions
        {
            ResourceTransformations = new List<ResourceTransformation>
            {
                IgnoreCreatedDateTags
            }
        };
    }

    public ResourceTransformationResult? IgnoreCreatedDateTags(ResourceTransformationArgs args)
    {
        var tagp = args.Args.GetType().GetProperty("Tags");
        
        if (tagp != null)
        {
            args.Options.IgnoreChanges = new List<string> { "tags." + TagHelper.CreatedDate };
        }
        return new ResourceTransformationResult(args.Args, args.Options);
    }

Nothing has changed from our end for it to suddenly throw an error related to the custom tag

Yeh as I said above I recently changed the ignore code which is probably what caused this to start erroring. But that ignore path does look like an invalid path because "tags" is an array and ignore paths don't work on values but just on property names and indices.

Right, so this behaviour has been changed for 3.72.2? Is there a fix we can do to stop this from breaking?

Just re-checking this, the change I was thinking of shouldn't be effecting this because it was specifically for array properties and also never actually got merged. Also the key is valid because it looks like "tags" is normally a dictionary, not an array like I thought. So it should be fine to ignore a specific key from it. Do you know what version of the CLI you were on before 3.72.2? We've had three releases in the last week it would help to narrow this search down to when this changed.

Thanks for digging further into this. The last version of the CLI this has worked was 3.69.0

OK I can have a look into 3.70

No, we are not using --targets as part of the deployment. We are using the GH Pulumi action to deploy