« Grrrr DevOps Pipeline... premier gros crash 😤/en » : différence entre les versions
Aller à la navigation
Aller à la recherche
Page créée avec « Grrrr DevOps Pipeline... first major crash 😤 » |
Page créée avec « </syntaxhighlight>WorkArround<syntaxhighlight lang="powershell"> $azAccountsVersion = (Get-Module -ListAvailable -Name Az.Accounts | Sort-Object Version -Descending | Select-Object -First 1).Version $dexResourceUrl = 'https://database.windows.net/' if ($azAccountsVersion -ge [Version]'5.0.0') { write-host "Az.Accounts 5.0.0 and above" $AccessTokenSecure = (Get-AzAccessToken -ResourceUrl $dexResourceUrl).Token $token = ConvertFrom-SecureString -Sec... » |
||
| (10 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
<languages/> | <languages/> | ||
I knew Microsoft had given a warning… but as usual, no one really took it seriously 😅 | |||
We work in a fullstack DevOps team, with scripts that call SQL procedures in thousands of Azure SQL databases, whether for maintenance, exports, cleanup… you know, the usual stuff. | |||
And for that, '''we use the token obtained with the Get-AzAccessToken function<code>Get-AzAccessToken</code>'''.. | |||
The catch? Microsoft continuously updates their backend. So the Azure Pipeline pool that runs our PowerShell scripts gets updated automatically, without any action on our part. | |||
And this Sunday… boom 💥: they updated the Az.Accounts module from version 4 to 5, with a major breaking change: | |||
The token is no longer returned as a String, but as a SecureString! | |||
The result? All the older functions that handle these tokens can’t read them anymore, and everything breaks. In production. 😩 | |||
The worst part? Since everything runs in the backend, we don’t get any warnings, so no one saw it coming. It was only after the exports started failing that we realized what was going on. | |||
🎓 Lesson learned: never ignore warnings… even if they're buried deep in the logs. | |||
🔧 Fix: you need to add the -AsPlainText parameter in some cases, or completely revise how the token is handled depending on the module version used. | |||
Here’s the warning we should have taken seriously: | |||
<syntaxhighlight lang="pwsh"> | <syntaxhighlight lang="pwsh"> | ||
get-azaccesstoken | get-azaccesstoken | ||
| Ligne 44 : | Ligne 29 : | ||
- The change is expected to take effect in Az.Accounts version : '5.0.0' | - The change is expected to take effect in Az.Accounts version : '5.0.0' | ||
Note : https://aka.ms/azps-changewarnings | Note : https://aka.ms/azps-changewarnings | ||
</syntaxhighlight>WorkArround<syntaxhighlight lang="powershell"> | </syntaxhighlight>WorkArround<syntaxhighlight lang="powershell"> | ||
$azAccountsVersion = (Get-Module -ListAvailable -Name Az.Accounts | Sort-Object Version -Descending | Select-Object -First 1).Version | $azAccountsVersion = (Get-Module -ListAvailable -Name Az.Accounts | Sort-Object Version -Descending | Select-Object -First 1).Version | ||
| Ligne 59 : | Ligne 42 : | ||
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
[[Catégorie:Boîte à idées]] | [[Catégorie:Boîte à idées]] | ||
Dernière version du 5 juin 2025 à 14:55
I knew Microsoft had given a warning… but as usual, no one really took it seriously 😅
We work in a fullstack DevOps team, with scripts that call SQL procedures in thousands of Azure SQL databases, whether for maintenance, exports, cleanup… you know, the usual stuff.
And for that, we use the token obtained with the Get-AzAccessToken functionGet-AzAccessToken..
The catch? Microsoft continuously updates their backend. So the Azure Pipeline pool that runs our PowerShell scripts gets updated automatically, without any action on our part.
And this Sunday… boom 💥: they updated the Az.Accounts module from version 4 to 5, with a major breaking change:
The token is no longer returned as a String, but as a SecureString!
The result? All the older functions that handle these tokens can’t read them anymore, and everything breaks. In production. 😩
The worst part? Since everything runs in the backend, we don’t get any warnings, so no one saw it coming. It was only after the exports started failing that we realized what was going on.
🎓 Lesson learned: never ignore warnings… even if they're buried deep in the logs.
🔧 Fix: you need to add the -AsPlainText parameter in some cases, or completely revise how the token is handled depending on the module version used.
Here’s the warning we should have taken seriously:
get-azaccesstoken
WARNING: Upcoming breaking changes in the cmdlet 'Get-AzAccessToken' :
The Token property of the output type will be changed from String to SecureString. Add the [-AsSecureString] switch to avoid the impact of this upcoming breaking change.
- The change is expected to take effect in Az version : '14.0.0'
- The change is expected to take effect in Az.Accounts version : '5.0.0'
Note : https://aka.ms/azps-changewarnings
WorkArround
$azAccountsVersion = (Get-Module -ListAvailable -Name Az.Accounts | Sort-Object Version -Descending | Select-Object -First 1).Version
$dexResourceUrl = 'https://database.windows.net/'
if ($azAccountsVersion -ge [Version]'5.0.0') {
write-host "Az.Accounts 5.0.0 and above"
$AccessTokenSecure = (Get-AzAccessToken -ResourceUrl $dexResourceUrl).Token
$token = ConvertFrom-SecureString -SecureString $AccessTokenSecure -AsPlainText
} else {
write-host "Az.Accounts below 5.0.0"
$token = (Get-AzAccessToken -ResourceUrl $dexResourceUrl).Token
}