-
Notifications
You must be signed in to change notification settings - Fork 157
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
import-module vsteam loses previously stored configuration #493
Comments
I think the problem was introduced in commit 0528c76 due #467 and closed with #480 While loading the module, if there is a default project, it executes But:
I managed to make it work with # set vsteam account to initialize given variables properly
$pat = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($env:TEAM_PAT)) #decode base64 stored pat
$pat = $pat.Substring(1) #remove the leading :
$defaultProject = $env:TEAM_PROJECT #save temporary defalt project because is removed during Set-VSTeamAccount call
Set-VSTeamAccount -Account $env:TEAM_ACCT -PersonalAccessToken $pat -Version $env:TEAM_VERSION
# Make sure the value in the environment variable still exisits.
if (Get-VSTeamProject | Where-Object ProjectName -eq $defaultProject) {
Set-VSTeamDefaultProject -Project $defaultProject
}
else {
Write-Warning "The default project '$defaultProject' stored in the environment variable TEAM_PROJECT does not exist."
} but still not resolved the issue that security was configured with -UserBearerToken parameter instead -PersonalAccessToken |
What's the best way to get this resolved? I'm currently working around this by adding the following to my PowerShell profile after importing the VSTeam module: Set-VSTeamAccount -Account 'Foo' -Level 'User' -SecurePersonalAccessToken $securePAT
Set-VSTeamDefaultProject -Project 'Bar' -Level 'User' Much thanks for @mnieto for identifying the issue and creating pull request #508! |
This pull request resolves two main issues. First, it fixes bug #493 where the `import-module vsteam` command was causing loss of previously stored configurations. Second, it corrects the 'Versions' test failure on local setups when `Set-VSTeamAccount` is used with the `-Local` parameter. This issue didn't surface during GitHub builds due to the `TEAM_VERSION` variable not being set. In addition to these fixes, the pull request includes updates to the change log and documentation. --------- Co-authored-by: Sebastian S Schütze <[email protected]>
Steps to reproduce
Once configured the module with Set-VSTeamAccount:
If we close the powersell session and open a new one:
output
Then, import the module and test the env variables:
output now is:
We lost the version, default project and TEAM_PAT has changed
Because the last one, we cannot connect to azure services and we need to run
Set-VSTeamAccount
in each new powershell sessionExpected behavior
Configuration is recovered from previous sessions
Actual behavior?
TEAM_PAT has change and default project name and Version are lost
We cannot connect to azure services and we need to run
Set-VSTeamAccount
in each new powershell sessionThis happen in version 7.9.0
On Which OS have you tried it?
Windows
What was your server version?
Azure DevOps Services
Other server version
No response
Log output of used API
Log output of $PSVersionTable
$PSVersionTable Name Value ---- ----- PSVersion 7.2.6 PSEdition Core GitCommitId 7.2.6 OS Microsoft Windows 10.0.19044 Platform Win32NT PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…} PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 WSManStackVersion 3.0
The text was updated successfully, but these errors were encountered: