Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jsloan117 opened this issue Nov 3, 2022 · 50 comments
Closed
Assignees
Labels
Area:RM RM task team

Comments

@jsloan117
Copy link

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
Copy link

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
Copy link

Poovamma commented Nov 4, 2022

+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
Copy link

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

@IanMoroney
Copy link

@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
Copy link

We are seeing this in our pipelines as well.

@schrx1964
Copy link

schrx1964 commented Nov 7, 2022

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

@gpkrieger
Copy link

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
Copy link

+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
Copy link

+1 seeing this as well across multiple customers

@gorziza
Copy link

gorziza commented Nov 8, 2022

We have the same problem!

@thophan-microsoft
Copy link

+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
Copy link

at-besa commented Nov 9, 2022

+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
Copy link

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

@jcontti-axa
Copy link

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

@v-mohithgc
Copy link
Contributor

Task version has been rolled back to 1.211.2

@jwikman
Copy link

jwikman commented Nov 9, 2022

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
Copy link
Contributor

v-mohithgc commented Nov 9, 2022

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
Copy link

jwikman commented Nov 9, 2022

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
Copy link

at-besa commented Nov 9, 2022

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
Copy link

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
Copy link

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

@v-mohithgc
Copy link
Contributor

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

@hilari0n
Copy link

hilari0n commented Nov 14, 2022

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
Copy link

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

@hilari0n
Copy link

The issue is also being raised on the StackOverflow.

@jsloan117
Copy link
Author

#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
Copy link

jwikman commented Nov 15, 2022

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
Copy link
Contributor

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
Copy link

it's fixed for me after the revert

@Sander-IctQ
Copy link

Sander-IctQ commented Nov 16, 2022

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
Copy link

andrii-lundiak commented Nov 17, 2022

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
Copy link

bdbvb commented Nov 18, 2022

#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
Copy link

ArPharazon commented Nov 20, 2022

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
Copy link

skkulla commented Nov 23, 2022

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
Copy link

swenkeratmicrosoft commented Nov 23, 2022

@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
Copy link
Contributor

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
Copy link

cdcadman commented Dec 5, 2022

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
Copy link

With version 213 the warning is gone on our side.

@github-actions
Copy link

github-actions bot commented Jun 3, 2023

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

@github-actions github-actions bot added the stale label Jun 3, 2023
@hilari0n
Copy link

hilari0n commented Jun 4, 2023

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?

@github-actions github-actions bot removed the stale label Jun 4, 2023
@v-mohithgc
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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

khan962022 added a commit to khan962022/lesson-learned that referenced this issue Jul 11, 2023
@fvilches17
Copy link

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
Copy link
Contributor

@fvilches17 version 1.225.1 will contain the fix.

@ThomasArdal
Copy link

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

@v-mohithgc
Copy link
Contributor

v-mohithgc commented Jul 26, 2023

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
Copy link

Seems like it is still an issue:

image

@v-mohithgc
Copy link
Contributor

Seems like it is still an issue:

image

apologies, version 2.225.0 will contain the fix. Here is the PR #18592.

@v-mohithgc v-mohithgc self-assigned this Aug 9, 2023
@v-mohithgc v-mohithgc added the Area:RM RM task team label Aug 9, 2023
@v-mohithgc
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area:RM RM task team
Projects
None yet
Development

No branches or pull requests