[All OSes] Powershell Core will be updated to 7.4.x LTS on January, 28

[mikhailkoliada]

Breaking changes

Powershell Core on all runners will be switched from the 7.2.x LTS branch to the 7.4.x LTS one. The description of the changes can be found on Microsoft learn and in the dev blog.

Target date

The images rollout process will start on January 28 and take 3-4 days.

The motivation for the changes

According to the support lifecycle the 7.2.x branch will have reached its end of life by November, 8 this year and we would like to provide the latest LTS versions.

Possible impact

We do not expect any major breakages, though we highly recommend study all the changelogs from the links above to avoid unexpected behaviour.

Platforms affected

• Azure DevOps
• GitHub Actions

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• macOS 13
• macOS 13 Arm64
• Windows Server 2019
• Windows Server 2022

Mitigation ways

Here are the runtime downgrade paths if 7.2.x is still needed:

Windows:

        set "extractPath=C:\Program Files\PowerShell\7"
        curl -sLO https://github.com/PowerShell/PowerShell/releases/download/v7.2.17/PowerShell-7.2.17-win-x64.zip
        RMDIR "%extractPath%" /S /Q
        7z x PowerShell-7.2.17-win-x64.zip -o"%extractPath%"
        pwsh --version

Linux:

        sudo apt-get remove powershell
        curl https://packages.microsoft.com/config/ubuntu/22.04/packages-microsoft-prod.deb -o packages-microsoft-prod.deb
        sudo dpkg -i packages-microsoft-prod.deb
        sudo apt-get update
        sudo apt-get install -y powershell=7.2.17-1.deb
        pwsh --version

macOS:

        curl -L -o powershell.pkg https://github.com/PowerShell/PowerShell/releases/download/v7.2.17/powershell-7.2.17-osx-arm64.pkg
           sudo installer -pkg powershell.pkg -target /
           pwsh --version

[kilasuit]

As part of this work package can I please ask for the following additional enhancements as this would greatly benefit the community and has previously been asked for by myself & generally makes sense to enable this pattern not only for PowerShell but other tooling too to reduce unnecessary and painful custom pre-execution scripts or custom tasks to enable more flexible testing matrixes that are much needed going forward.

• Add a settable specific version option
• Add a use Preview version option
• Add a use Daily build option
• Add a use Stable version option - This is less needed now that we are on an LTS release but will in future be required between this LTS and the next LTS release so makes sense to just add it now and save on the future work needed to add it

Without any of those settings being set it should still default to using the latest LTS release as planned

[Jaykul]

@kilasuit Once 7.5 comes out, having the latest stable as an option makes sense, and would be in line with other tools. I would think anything beyond that would be a matter for a tool installer task, no?

[kilasuit]

Which I expect is already the task used for installing PowerShell on the images in the first place, which as part of this work package would need to be updated anyway, to use the latest version, so I don't see why asking for that task to be updated in such a way that when you then try call PowerShell as an action in your workflow with additional flags asked above is too much of an ask here.

This would allow in my mind for something like the below to be viable & nice and clean in GitHub/Azure DevOps yaml files

GitHub

shell: pwsh
run: Test-Path resultsfile.log | Should -Be $true
version: preview

shell: pwsh
run: Test-Path resultsfile.log | Should -Be $true
version: daily

shell: pwsh
run: Test-Path resultsfile.log | Should -Be $true
version: stable

shell: pwsh
run: Test-Path resultsfile.log | Should -Be $true
version: 7.3.6

Azure DevOps

pwsh: Write-Host Hello $(name)
displayName: Say hello
name: firstStep
workingDirectory: $(build.sourcesDirectory)
failOnStderr: true
env:
    name: Microsoft
version: preview

pwsh: Write-Host Hello $(name)
displayName: Say hello
name: firstStep
workingDirectory: $(build.sourcesDirectory)
failOnStderr: true
env:
    name: Microsoft
version: daily

pwsh: Write-Host Hello $(name)
displayName: Say hello
name: firstStep
workingDirectory: $(build.sourcesDirectory)
failOnStderr: true
env:
    name: Microsoft
version: stable

pwsh: Write-Host Hello $(name)
displayName: Say hello
name: firstStep
workingDirectory: $(build.sourcesDirectory)
failOnStderr: true
env:
    name: Microsoft
version: 7.3.6

and then that way this tells the runner to check for and if not installed, install the specified version to the runner as a setup task which would run prior to running that step and then use the referenced version for that step.

This may increase size of runner images over time as well as in some cases make a build a little slower, but eventually this'll help make management & maintenance easier for both cloud hosted and self hosted runners, even if it is a stretch goal in asking for it, but would be good to see happen

[fbrosseau]

For anyone hitting the same issue, this upgrade in powershell version brings the following breaking change around Invoke-WebRequest/Invoke-RestMethod with a null -OutFile: PowerShell/PowerShell#20744

The fix (which will work with both old and new pwsh) is to use splatting (see example in that thread).

[mikhailkoliada]

Deployed