In YAML Azure Pipeline, mapping and accessing a network share doesn't work properly when running the job in a container provided by ADO agents

Question

I am trying to run my pipeline in containers, I am using the inbuilt support that azure pipelines provide to run the jobs in containers via azure agents.

This is how my YAML looks:

resources:
  containers:
  - container: myContainerResource
    image: myregistry/image
    endpoint: 'azuredevops-service-connection'
    volumes:
    - 'C:\X:C:\X'
    - 'C:\Y:C:\Y'

stages:
- stage: 
  jobs:
  - job:
    pool:
      name: myPool
    container: myContainerResource

    steps:

    - powershell: |   # First Powershell task
        whoami   # This is printed as 'user manager\containeradministrator'

        net use \\share-path\folder1$ /user:$env:ACCOUNT $env:PASSWORD

        if (Test-Path -ErrorAction SilentlyContinue \\share-path\folder1$)
        {
            Write-Host "Mapping \\mr-fs01\midas$ finished successfully"  # This is executed
        }
        else
        {
          Write-Host "Mapping failed"
          exit 1
        }
        
        gc \\share-path\folder1$\myFile.txt  # The content of the file is accessible and printed
      env:
        ACCOUNT: $(USER_SECRET_FROM_VAR_GROUP_KEY_VAULT)
        PASSWORD: $(PWD_SECRET_FROM_VAR_GROUP_KEY_VAULT)
     
    - powershell: |        # Second Powershell task     
        whoami            
        gc \\share-path\folder1$\myFile.txt  # HERE THE SAME PATH IS NOT ACCESSIBLE, TROWS EXCEPTION

The 'net use' command executes properly in the first PowerShell task, and the files are also accessible. When I try to access the share or the files from the second PowerShell task, it throws exception as:

user manager\containeradministrator
gc : Access is denied
At C:\__w\_temp\0sdsd3-wewe-4d92234-2-xcxc3232.ps1:5 char:1
+ gc \\share-path\folder1$\myFile.txt
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (\\share-path\folder1$\myFile.txt:Stri 
   ng) [Get-Content], UnauthorizedAccessException
    + FullyQualifiedErrorId : ItemExistsUnauthorizedAccessError,Microsoft.Powe 
   rShell.Commands.GetContentCommand

Yes, I'm aware that it's possible to map the share as a volume, which can be used with my containers. However, my tests have hardcoded paths to the network share paths. Thus, I can't use the Docker volumes approach in this case. How can I make the second task access the network share that was perfectly mapped in the first task?

Answer 1

Based on the further discussions, the actual requirement is to run VSTest in a container agent environment, whose tests are written in a way that they access some dependencies from a hardcoded network share path.

As far as I tested, the VSTest pipeline task itself doesn't support such scenario to authenticate access to a network share path before executing the tests.

However, since we can use PowerShell script to authenticate access to that share path, I am thinking if we can run vstest in the same PowerShell session.

stages:
- stage: 
  jobs:
  - job:
    pool:
      name: myPool
    container: myContainerResource

    steps:

    - powershell: |   # First Powershell task
        whoami   # This is printed as 'user manager\containeradministrator'

        net use \\share-path\folder1$ /user:$env:ACCOUNT $env:PASSWORD

        if (Test-Path -ErrorAction SilentlyContinue \\share-path\folder1$)
        {
            Write-Host "Mapping \\mr-fs01\midas$ finished successfully"  # This is executed
        }
        else
        {
          Write-Host "Mapping failed"
          exit 1
        }
        
        gc \\share-path\folder1$\myFile.txt  # The content of the file is accessible and printed

        cd "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\Extensions\TestPlatform\"  # The location in the container where vstest.console.exe tool is installed
        .\vstest.console.exe "$(Build.SourceDirectory)\DotNetCore\DotNetCoreTests\bin\Debug\net7.0\DotNetCoreTests.dll" # Use vstest.console.exe to test the assemblies (dotnet tests in my case)
      env:
        ACCOUNT: $(USER_SECRET_FROM_VAR_GROUP_KEY_VAULT)
        PASSWORD: $(PWD_SECRET_FROM_VAR_GROUP_KEY_VAULT)