New-PartnerAccessToken does not return a refresh token under Linux

[slavizh]

Steps to reproduce

What steps can reproduce the defect?
Please share the setup, commandline for vstest.console, sample project, target
framework etc.

We are using New-PartnerAccessToken in a docker container of Ubuntu 18.04. The PowerShell script is run via Azure DevOps agent on PowerShell 6.2.3-1.ubuntu.18.04.
When using the following command:

$cspCredentials = New-Object System.Management.Automation.PSCredential ($applicationIdSecret.SecretValueText, $applicationSecret.SecretValue )
    $cspNewTokenParameters = @{
        ApplicationId = $applicationIdSecret.SecretValueText
        Credential = $cspCredentials
        RefreshToken = $refreshTokenSecret.SecretValueText
        Scopes = 'https://api.partnercenter.microsoft.com/user_impersonation'
        ServicePrincipal = $true
        Tenant = $tenantIdSecret.SecretValueText
        ErrorAction = 'Stop'
        ErrorVariable = 'lastError'
    }
    $cspToken = New-PartnerAccessToken @cspNewTokenParameters

The refresh token is not returned in variable $cspToken.RefreshToken. It is empty. $cspToken.AccessToken and other properties in the object are populated. For example CorrelationId : 47e26b5b-1b9a-4a1b-baa4-feb90ecd718c

Expected behavior

Share the expected output

Actual behavior

What is the behavior observed?

Diagnostic logs

Please share test platform diagnostics logs.
The logs may contain test assembly paths, kindly review and mask those before sharing.

Environment

Please share additional details about your environment.
Version

[slavizh]

Seems I have to use Register-PartnerTokenCache -InMemory to get it working. Is that the correct way? It is not documented.

@slavizh that command was added to swap between the in-memory and persistent token cache without having to create the control file. What you have done allows you to work around this issue, but it is not the intended solution for this particular problem.

[slavizh]

@IsaiahWilliams ok. Do you have enough information to investigate and find the root cause why it is happening on linux?

@slavizh I have discovered the root cause for what is happening. It has to contend with two dependencies for leveraging the persistent token cache. Considering you are running everything through a pipeline, I believe that it would be best to use the in-memory token cache instead. That way you do not have to worry about ensuring the dependencies are installed and configured. I am still looking into additional options to address this gap.

@slavizh with the upcoming release the underlying issue for this issue will be resolved. Also, I am planning to update the documentation to state that both Gnome Keyring and libsecret are requirements for a preseistent token cache when using Linux. If those are not option, then using the in-memory feature is your best option.

[marioroy]

Thank you, @slavizh and @IsaiahWilliams. We hit a wall today with testing on Linux. The in-memory feature works.