Allow outputting logs of updated / deleted keys with Azure App Configuration Push task when Dry Run is false

[brental]

Currently the Azure App Configuration Push task outputs a list of which keys would have been updated / deleted if Dry Run is set to true. However, when Dry Run is set to false it only outputs how many records have been updated. Would it be possible to get an option to output a list of the keys that were updated / deleted when Dry Run is set to false?

[zhenlan]

@brental, we try not to log the actual key-values as they may contain sensitive data, and logs often have less restrictive permission for access than an App Configuration store. In general, I recommend not logging them, even if it's possible. Could you please share how the logging of key-values could be useful to you?

[brental]

@zhenlan My thoughts are that it would be useful to see a list of the keys that were added, updated and deleted as part of the push to ensure nothing unexpected happened. This output doesn't have to include the values of each key, it could just include the keys themselves similar to the output when dry run is true. This would avoid the issue of exposing sensitives values.

This can currently almost be achieved by running the task twice. The first time doing a "dry run" to display the summary of what will be done and the second time doing an actual push. However, there is the possibility that the app configuration changes between the two and thus the "dry run" doesn't represent the result of the actual push. This possibility increases if there is additional time between the two so it would be good to be able see the result of the actual push in more detail to see more easily if the push did something unexpected.

This would also bring it into line with the Azure CLI App Configuration import / export commands that are being updated to display output both when running with and without the --yes argument as part of #712.

I believe those two CLI commands also show the values of the keys in the output but hide sensitive values so perhaps the logic for hiding those values could be used in this push task. However, if that is not possible having the output of the keys only still seems useful.

[zhenlan]

@brental, thanks for sharing your thoughts.

@MaryanneNjeri, any thoughts on how users can enable verbose logs?

[MaryanneNjeri]

@zhenlan am thinking we can support an optional input (something like Log updated key-values) with the default as false, but when users opt-in, keys that have been updated/deleted are logged.

[zhenlan]

@MaryanneNjeri does the Pipeline task have any built-in properties for log verbosity?

[MaryanneNjeri]

@zhenlan the pipeline task does have the option to configure logs to be more verbose by setting system.debug to true, but since we don't log anything when dry run is set to false, updated/deleted keys will not be part of the logs.

[zhenlan]

@brental would it be a viable solution for you if we log keys when you set system. Debug to true?

[brental]

@zhenlan Sorry for the lack of reply. Using System.Debug could work, but are there any other common approaches used in tasks to enable more verbose logs? My concern with System.Debug is that it will also increase logs for all tasks in the pipeline which might not be desirable for every run. Unless there is a way to set System.Debug for a single task?

[brental]

@zhenlan I am just following up on this to see if it is still an option. I feel like the opt in parameter that @MaryanneNjeri mentioned is probably a better option then using System.Debug (see my comment above).

[zhenlan]

@brental sorry for my late response. What you said makes sense to me. Since this is only about logging the updated keys (like dry run), the verbose log may not be a good name for it (too generic). We will figure out something else.