Warnings about Resource file already set when using AzureKeyVault v1.212.0

[jsloan117]

Required Information

Type: Bug

Enter Task Name: AzureKeyVault

Environment

• Agent - Private:
  • OS: RHEL7
  • Version: 2.211.1

Issue Description

Dozens of warnings about "Resource file already set". This started today, from what I can tell.

##[warning]Resource file has already set to: /opt/buildagent/_work/_tasks/AzureKeyVault_1e244d32-2dd4-4165-96fb-b7441ca9331e/1.212.0/node_modules/azure-pipelines-tasks-azure-arm-rest-v2/module.json

[jdaugherty]

For us, this started happening in a build done on Nov 1st at 1:51 PM. It did not occur in the previous build that ran on Oct 26 at 6:01 PM. It's happening in the pre-job task for us, where it transfers secrets from the keyvault to populate the library values.

[Poovamma]

+1 . We are facing issues with the same. We are seeing multiple warnings while fetching secrets from Azure Key vault using the task

• task: AzureKeyVault@1

Error

##[warning]Resource file has already set to: /azp/agent/_work/_tasks/AzureKeyVault_1e244d32-2dd4-4165-96fb-b7441ca9331e/1.212.0/node_modules/azure-pipelines-tasks-azure-arm-rest-v2/module.json

[IanMoroney]

This just started happening for us too, and i get 12+ warnings in some pipelines.

[IanMoroney]

@chshrikh , @thesattiraju , @tauhid621 could someone get this bug assigned and resolved? It's causing too many false positives and devs have now started ignoring warnings altogether in the pipelines.

[Turbofroggy]

We are seeing this in our pipelines as well.

[schrx1964]

we are seeing this in our build pipelines again since a couple of days. Last Tuesday everything was still ok.

[gpkrieger]

We are seeing this in our build pipelines as well, the pipelines finish successfully, but it doesn't seem to be actually updating with values from the keyvault. to test, I deleted one of my keys used in the pipeline, and the pipeline still finished successfully, and the app still used the old key value.

[JagadeeshVenkatesan]

+1 I started seeing these warnings from Friday onwards and still see them in all my pipelines(100+), can anyone help me with it?

[NordbergDK]

+1 seeing this as well across multiple customers

[gorziza]

We have the same problem!

[thophan-microsoft]

+1 Our team started seeing this issue on October 31st with version 1.212.0. The previous version, 1.211.2 did not have this issue. Is there any plan to update to a new version with a fix, or something we can do on our end to resolve the warnings?

[at-besa]

+1 We also started seeing this issue in our pipelines about a week ago. This also turned out that most of the people ignore the warnings now.

[AnkitPathak41]

+1 We are also facing the same issue more than 300 warnings for keyvault task in Azure DevOps pipeline

[jcontti-axa]

• 1 same problem here, more than 200 warnings :(

[v-mohithgc]

Task version has been rolled back to 1.211.2

[jwikman]

We've got AzureKeyVault auto updated to v1.212.0 on a lot of our self-hosted server agents.

Is there any easy way to revert all those to v1.211.2?

[v-mohithgc]

We've got AzureKeyVault auto updated to v1.212.0 on a lot of our self-hosted server agents.

Is there any easy way to revert all those to v1.211.2?

Hi, you can try to clean agent tasks cache.

Example path: {agentname}\ _work \ _tasks *

[jwikman]

We've got AzureKeyVault auto updated to v1.212.0 on a lot of our self-hosted server agents. Is there any easy way to revert all those to v1.211.2?

Hi, you can try to clean agent tasks cache.

Example path: {agentname}\ _work \ _tasks *

It was just the "try" part I wanted to avoid... 😁 I noticed those files in each agent folder but wanted to be sure that I didn't screw things up before I did this.

I'll try to find a good agent to test this on later.

[at-besa]

We've got AzureKeyVault auto updated to v1.212.0 on a lot of our self-hosted server agents. Is there any easy way to revert all those to v1.211.2?

Hi, you can try to clean agent tasks cache.

Example path: {agentname}\ _work \ _tasks *

I already tried that and it does not help, these warnings appear immediatly with the first run after cleaning.

[That1Guy007]

We are also running into this issue. Any resolution so far? It is for our download secrets task from a variable group that is linked to an azure key vault.

[Turbofroggy]

I have a support request put in for this, will reply in here when I hear from them.

[v-mohithgc]

https://github.com/microsoft/azure-pipelines-tasks/pull/17151 revert is completed, will take time to roll out 213

[hilari0n]

We're using Azure DevOps and Hosted Agents and we're not directly referencing this task in our pipelines, but we are using variable groups, defined based on Azure KeyVault, which probably causes implicit use of this task (it shows up in the log, with version 1.212.0). This basically translates to all of our pipelines being affected by this issue, with no way to address it, without remaking all our pipelines to explicitly use the task in a corrected version.

[abatishchev]

@v-mohithgc can you please share the status of the rollout? namely when the new version is expected to land on msazure?

[hilari0n]

The issue is also being raised on the StackOverflow.

[jsloan117]

17151 revert is completed, will take time to roll out 213

This reverted fixed our issues. Although from what's being reported after this revert, it doesn't appear to be fixed for everyone.

[jwikman]

I'm having the same setup as @hilari0n, on hosted agents with variable groups. My agents are still downloading 1.212.0 of AzureKeyVault... I've tried to delete the 1.212.0 folder and files from the [agent folder]\_work\_tasks\AzureKeyVault_1e244d32-2dd4-4165-96fb-b7441ca9331e folder, but 1.212.0 is downloaded as soon as I start a pipeline. The agent is running version 2.213.2.

When can we expect that 1.213.0 is in use when variable groups are used? I've got more than a hundred pipelines affected by this, so refactoring from variable groups to explicit use of the AzureKeyVault task isn't appealing.

[tomaustin700]

Like others have said; this happens when a pipeline references a variable group linked to a Key Vault. It doesn't seem to cause any actual issues but I've got 252 warnings thrown in one of my largest pipelines.

[IanMoroney]

it's fixed for me after the revert

[Sander-IctQ]

The agent is running version 2.213.2, and started with a clean set of agents and we are still getting the message:

Resource file has already set to: /azp/agent/_work/_tasks/AzureKeyVault_1e244d32-2dd4-4165-96fb-b7441ca9331e/1.212.0/node_modules/azure-pipelines-tasks-azure-arm-rest-v2/module.json

[andrii-lundiak]

BAD At first I used variables group defined in AzureDevOps Library section with reusing dedicated (filtered out) KeyVault values (via KeyVault Connection) and as turned out AzureKeyVault was 1.212.0 was in usage and the the issue flow is almost exactly as @hilari0n described.

##[warning]Resource file has already set to: 
/home/vsts/work/_tasks/AzureKeyVault_***244*****33**
/1.212.0/node_modules/azure-pipelines-tasks-azure-arm-rest-v2/module.json

I tried different combinations with library and KeyVault, but issue still was happening.

OK I then detached from using Library entry, and I configured AzureKeyVault task in my YAML file directly as such:

 - task: AzureKeyVault@1 
    inputs:
      azureSubscription: $(myAzureSubscription)
      KeyVaultName: $(myKeyVaultName)
      runAsPreJob: false
      SecretsFilter: 'MYSECRETKEY'

Actual version got as 1.211.2 WHICH IS with NO issues (no warnings).

OK This way I've realized, that I really narrow down filtered out number of secrets, which is OK but still doesn't answer why that warning wasn't there and then appeared.

WEIRD but OK Anyway, I got from above comments and mentioned PRs that official version for azure-pipelines-tasks-azure-arm-rest-v2 package got reverted, and now I decided to also TRY using AzureKeyVault@2 as the latest, which got me 2.211.1 actual version. AzureKeyVault task worked OK - no warnings.

OK vs. OK So looks like, for now there are two ways:

• Use exact but downgraded version AzureKeyVault@1 or AzureKeyVault@1.211.2.
• Use latest AzureKeyVault@2 version 2.211.1.

[bdbvb]

17151 revert is completed, will take time to roll out 213

@v-mohithgc

When I run a YAML pipeline with a build stage and a deployment stage, the build stage gets the offending version (1.212.0), whereas the deployment stage gets the reverted version (1.211.2).

Steps to reproduce:

• In Azure Devops create a project with a Git repo and a YAML pipeline. The YAML is listed below.
• In Azure, create a Key Vault with a secret named “a-secret” with an arbitrary value.
• In the Azure DevOps project, under Pipelines > Library, create a variable group called BuildSecrets, link that to the Key Vault mentioned above, and select “a-secret” as one of the variables.
• Run the pipeline.
• Look in the execution logs and see warnings.

name: $(Build.DefinitionName)_$(Year:yy)$(DayOfYear)$(Rev:.r)

trigger:
- main

pool:
  vmImage: windows-2022

stages:
- stage: Build
  displayName: Build
  variables:
    - group: BuildSecrets
    # mapped standard variables for secrets
    - name: my-secret
      value: $(a-secret)
  jobs:
  - job: MyJob
    steps:
    - script: echo '$(my-secret)'

- stage: ReleaseDev
  displayName: Release-Dev
  dependsOn: Build
  condition: succeeded()
  variables:
    - group: BuildSecrets
    # mapped standard variables for secrets
    - name: my-secret
      value: $(a-secret)
  jobs:
  - deployment: Release
    environment: Dev
    strategy:
      runOnce:
        deploy:
          steps:
          - pwsh: echo '$(my-secret)'

The same sort of thing happens for me with a single on-prem build agent.

[ArPharazon]

I'm still seeing keyvault version 1.212.0 in our hosted build agent logs.

2022-11-20T07:05:34.5946940Z ##[section]Starting: Download secrets: xxxxxxxxxxxxxxxxxx
2022-11-20T07:05:34.6201738Z ==============================================================================
2022-11-20T07:05:34.6202822Z Task         : Azure Key Vault
2022-11-20T07:05:34.6203471Z Description  : Download Azure Key Vault secrets
2022-11-20T07:05:34.6203782Z Version      : 1.212.0
2022-11-20T07:05:34.6204541Z Author       : Microsoft Corporation
2022-11-20T07:05:34.6205170Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/deploy/azure-key-vault
2022-11-20T07:05:34.6205611Z ==============================================================================
2022-11-20T07:05:35.1724980Z ##[warning]Resource file has already set to: /home/vsts/work/_tasks/AzureKeyVault_1e244d32-2dd4-4165-96fb-b7441ca9331e/1.212.0/node_modules/azure-pipelines-tasks-azure-arm-rest-v2/module.json
2022-11-20T07:05:35.1737798Z ##[warning]Resource file has already set to: /home/vsts/work/_tasks/AzureKeyVault_1e244d32-2dd4-4165-96fb-b7441ca9331e/1.212.0/node_modules/azure-pipelines-tasks-azure-arm-rest-v2/module.json
2022-11-20T07:05:35.1740612Z ##[warning]Resource file has already set to: /home/vsts/work/_tasks/AzureKeyVault_1e244d32-2dd4-4165-96fb-b7441ca9331e/1.212.0/node_modules/azure-pipelines-tasks-azure-arm-rest-v2/module.json
2022-11-20T07:05:35.1850162Z ##[section]Finishing: Download secrets: xxxxxxxxxxxxxxxxxx

How do we get the fixed version ?

[skkulla]

I am running into the same issue using Variable group, is there a way to define Azure Key Vault version to use when defining the variable group in pipelines.

[swenkeratmicrosoft]

@chshrikh , @thesattiraju , @tauhid621 - my team is completely ignoring all warnings in pipelines until this is fixed because it's showing us so many false alarms - hundreds per day.

I'm a Microsoft internal FTE, so feel free to contact me directly for a repro, logs, anything you need to get this resolved sooner. There appears to be a claim that it's fixed (above), but the fix still isn't showing up two weeks later.

[v-mohithgc]

Hi all, Quick update: Azure KV version 213 (both task and variable group) which fixes the warning issue, has been rolled out to south Brazil and EUS2 region for now. There is a slight delay, but version 213 will be rolled out to all regions and users by end of December 1st week.

[cdcadman]

Starting with version 1.213.0, this warning is showing up in the PipAuthenticate@1 task. The task seems to be working correctly aside from the warning. Previously, we were using version 1.206.0.

[DanielGoehler]

With version 213 the warning is gone on our side.

[github-actions[bot]]

This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days

[hilari0n]

Can someone confirm if this is addressed and where (which tasks) have this addressed? Companies are paying a crap ton of money for MSDN subscriptions/licenses, which cover the Azure DevOps, plus another crap ton of money for additional services on Azure DevOps (like hosted agents) and we can't even get an update on if an issue is resolved or not. Do we need to pay for that separately? Is it like with Apple products, that you have to pay for each and every feature separately?

[v-mohithgc]

Can someone confirm if this is addressed and where (which tasks) have this addressed? Companies are paying a crap ton of money for MSDN subscriptions/licenses, which cover the Azure DevOps, plus another crap ton of money for additional services on Azure DevOps (like hosted agents) and we can't even get an update on if an issue is resolved or not. Do we need to pay for that separately? Is it like with Apple products, that you have to pay for each and every feature separately?

Hi, in which task are you experiencing these warnings.?

[timtucker-dte]

We're seeing it in AzureAppServiceSettings tasks every time that they run. Version: 1.223.0

Looking at old logs, I doesn't look like it was happening in 1.215.0, but it was happening in 1.221.102

[v-mohithgc]

Warning issue related to AzureAppServiceSetting and AzureResourceGroupDeployment has been addressed. The fix will be rolled out soon in version 224.

[fvilches17]

At time of writing (26 Jul 2023): I'm getting this issue with task AzureWebApp@1 version 1.225.0

2023-07-25T23:57:44.8421143Z ##[section]Starting: Deploy WebApp
2023-07-25T23:57:44.8426147Z ==============================================================================
2023-07-25T23:57:44.8426279Z Task         : Azure Web App
2023-07-25T23:57:44.8426357Z Description  : Deploy an Azure Web App for Linux or Windows
2023-07-25T23:57:44.8426450Z Version      : 1.225.0
2023-07-25T23:57:44.8426514Z Author       : Microsoft Corporation
2023-07-25T23:57:44.8426596Z Help         : https://aka.ms/azurewebapptroubleshooting
2023-07-25T23:57:44.8426682Z ==============================================================================
2023-07-25T23:57:45.2901880Z ##[warning]Resource file has already set to: /home/vsts/work/_tasks/AzureWebApp_18bde28a-8172-45cb-b204-5cef1393dbb1/1.225.0/node_modules/azure-pipelines-tasks-azure-arm-rest-v2/module.json
2023-07-25T23:57:45.2941925Z Got service connection details for Azure App Service:'<app>'
2023-07-25T23:57:52.0968295Z Package deployment using ZIP Deploy initiated.
2023-07-25T23:58:12.6896647Z Deploy logs can be viewed at <link>
2023-07-25T23:58:12.6897019Z Successfully deployed web package to App Service.
2023-07-25T23:58:19.8789852Z Successfully updated deployment History at <link>
2023-07-25T23:58:20.5368868Z App Service Application URL: <url>
2023-07-25T23:58:22.6338825Z ##[section]Finishing: Deploy WebApp

[v-mohithgc]

@fvilches17 version 1.225.1 will contain the fix.

[ThomasArdal]

I'm seeing this on both 1.x and 2.x of the Azure Functions Deploy task on a Hosted agent.

[v-mohithgc]

I'm seeing this on both 1.x and 2.x of the Azure Functions Deploy task on a Hosted agent.

Hi @ThomasArdal , version 224 of Azure Function Deploy V2 and version 225.1 of V1 task will contain the fix for this issue.

Version 224 of Azure Function Deploy V2 should be out to all the regions by now, please rerun and confirm. Thanks

[ThomasArdal]

Seems like it is still an issue:

[v-mohithgc]

Seems like it is still an issue:

apologies, version 2.225.0 will contain the fix. Here is the PR https://github.com/microsoft/azure-pipelines-tasks/pull/18592.

[v-mohithgc]

This issue is now resolved, feel free to reopen if the issue still persist. Thanks