Conflict with Standard Environment Variables in Azure Services and RemoteCache

[mmslakr]

We've recently begun utilizing the Powerpack Azure RemoteCache. According to the documentation, setting up authentication requires defining standard environment variables. By standard, I refer to the variable names that the Azure SDK(s) look for by default. This is quite convenient... until it becomes an issue.

We are integrating Azure services within our applications and tools in the repository. Additionally, we use Pulumi and store its state in Azure Blob Storage. With the introduction of these standard environment variables, some tools are now prioritizing these variables.

The cache authentication appears to take precedence over the primary ownership of these global environment variables. Since we operate everything through the task runner, this poses a significant challenge for us.

I recognize that this may not be a concern for those who are not using Azure services or storage in their repository, aside from the remote cache.

I’ve marked this as a feature request because I believe a solution could be to introduce a second, more specific environment variable that @nx/powerpack-azure-cache could also evaluate.

For example, using NX_CACHE_AZURE_STORAGE_CONNECTION_STRING instead of AZURE_STORAGE_CONNECTION_STRING.

However, I am open to any suggestions or insights that could help address this issue.