windows-latest workflows will use Windows Server 2022

[miketimofeev]

Breaking changes

Windows Server 2022 is ready to be the default version for the "windows-latest" label in GitHub Actions and Azure DevOps.

Target date

This change will be rolled out over a period of several weeks beginning on January, 17. We plan to complete the migration by March, 6.

The motivation for the changes

Starting from November 2021 Windows Server 2022 with Visual Studio 2022 image is generally available for all customers. We have monitored customer feedback to improve the Windows Server 2022 image stability and now we are ready to set it as the latest.

Possible impact

⚠️ CodeQL does not currently support analysis of compiled languages on Windows Server 2022 ⚠️ Support for Windows Server 2022 has been added.

The Windows Server 2022 image has a different set of software than Windows Server 2019. The most significant changes are listed in the table below:

Tool name	Windows-2019	Windows-2022	Notes
Go lang	1.15.*	1.16.*	Go lang version bumped to the more recent one
Python	3.7.*	3.9.*	Python version bumped to the more recent one
Ruby	2.5.*	3.0.*	Ruby version bumped to the more recent one
Google Cloud SDK	latest	-	The software was removed due to maintenance concerns, consider using the official action https://github.com/google-github-actions/setup-gcloud
Innosetup	latest	-	The software was removed due to its low popularity and maintenance concerns
Parcel	latest	-	The software was removed due to its low popularity and maintenance concerns
Cloud Foundry CLI	latest	-	The software was removed due to its low popularity and maintenance concerns
Java	8(default) 11 13 17	8(default) 11 17	Due to our software guidelines we left only LTS versions on the image. If you need to use other versions of Java, consider using setup-java and Java tool installer tasks
Python toolcache	2.7 3.5 3.6 3.7 3.8 3.9 3.10	3.7 3.8 3.9 3.10	EOL python versions were removed
PyPy toolcache	2.7 3.6 3.7 3.8	2.7 3.7 3.8	Version 3.6 was deprecated as it won't receive any updates
Ruby toolcache	2.4 2.5(default) 2.6 2.7 3.0	2.7 3.0(default)	Left only two recent versions
MySQL	5.7.*	8.0.*	The version was updated to the latest major one
.NET	2.1 3.1 5.0	3.1 5.0	Version 2.1 is EOL and was removed
Windows Driver Kit	10.0.*	-	VS2022 is not yet supported by the WDK
Az powershell module	1.0.0.zip 1.6.0.zip 2.3.2.zip 2.6.0.zip 3.1.0.zip 3.5.0.zip 3.8.0.zip 4.3.0.zip 4.4.0.zip 4.7.0.zip 5.5.0.zip 5.9.0.zip 6.5.0	6.5	Left only the most recent 6.* release
Android SDK build-tools and platforms	19 - 32	27 - 32	Android Platforms and build tools < 27.0 were removed from image. Consider installation in runtime using sdkmanager

Virtual environments affected

• Ubuntu 18.04
• Ubuntu 20.04
• macOS 10.15
• macOS 11
• Windows Server 2016
• Windows Server 2019
• Windows Server 2022

Mitigation ways

If you see any issues with your workflows during this transition period:

• File an issue in this repository
• Switch back to windows-2019 by specifying the windows-2019 label in your workflow. We will continue to support Windows Server 2019 image.

[tt2468]

Are there any known actions that we can use to install innosetup?

[iAkashPattnaik]

Are there any known actions that we can use to install innosetup?

Nah, I don't think that's possible from actions.

[miketimofeev]

@tt2468 innosetup can be installed relatively fast in runtime. Please feel free to ask for help if needed

[MellyDawgKY]

Why this was not done on the day of formally releasing visual studio 2022?

I always assumed Microsoft would follow the literal definition of 'latest' - silly me.

[neman]

What about LTS .NET 6.0?

[miketimofeev]

@neman 6.0 is bundled in VS2022, so it's available on the image but not installed via part of .NET installation script

[remyjette]

I'm seeing this warning

##[warning]windows-latest pipelines will use windows-2022 soon. For more details, see #4856

In all of my Windows pipelines, but none of my pipelines use windows-latest - they all use windows-2019.

[mikeKuester]

Why this was not done on the day of formally releasing visual studio 2022?

Same for me! mairaw mentioned the issue I opend. I think that the name "windows-latest" is totally misleading. Something like "..-stable" would fit much better to the reality.

[miketimofeev]

I'm seeing this warning

##[warning]windows-latest pipelines will use windows-2022 soon. For more details, see #4856

In all of my Windows pipelines, but none of my pipelines use windows-latest - they all use windows-2019.

Sorry for the inconvenience, this is a known issue and will be fixed next week.

[catthehacker]

Something like "..-stable" would fit much better to the reality.

-stable implies that it is more "stable" than other windows-* labels, which is not and would be even more misleading

[mikeKuester]

Ok, good point, do you have a better idea?

With "-latest" I expect the "latest bits and bytes". Not that several month after the release of the actual .NET 6 it's not included. :(

[catthehacker]

the label windows-* pertains to Windows version, not software it includes
since windows-2019 is Windows Server 2019 and windows-2022 is Windows Server 2022, naturally, windows-latest is latest GA version of Windows Server

[stap123]

FWIW

I agree windows-latest implies the most recent GA versions of stuff. This would mean that as soon as windows-2022 was GA then the -latest version should have switched over the same day (or close to it) not 6 months later (windows 2022 was GA in Sep).

When you take into consideration that .NET 6 was not available on the -2019 image on release day either it was a bit frustrating being encouraged to update to the latest .NET asap and then having to find out that it actually required changes to pipelines because -latest doesn't mean latest 🥲 Acknowledging that the solution was to pin to -2022 so not the end of the world it still meant confusion and frustration when the expectation was for the latest bits to be available.

There was a similar thing with Azure Functions last year with a many month lag between .NET 5 and support for it in functions. They worked to ensure that .NET 6 was supported on day 1 when that came out in Nov. Maybe there's a lesson to be learned there?

@mikeKuester
Another possible option would be to simply not offer a windows-latest and only offer pinned versions then people would have to take control of their own versions. I accept that makes it slightly more painful for people managing windows versions and many pipelines but it does remove the ambiguity.

[catthehacker]

I agree windows-latest implies the most recent GA versions of stuff. This would mean that as soon as windows-2022 was GA then the -latest version should have switched over the same day (or close to it) not 6 months later (windows 2022 was GA in Sep).

It takes time to work out all the quirks of new software when it's released to not break environment. Switching over to windows-2022 on day 0 would break a lot of pipelines/workflows as well as it would require for GHA team to have it available on that time in Azure environment. I'll admit it is my fault that I didn't put * with clarification that latest OS requires additional work, thorough testing and customer feedback before it can be released "in the wild" and all that combined takes time. What I originally meant by GA is GA in sense of OS vendor and GitHub Actions.

When you take into consideration that .NET 6 was not available on the -2019 image on release day either it was a bit frustrating being encouraged to update to the latest .NET asap and then having to find out that it actually required changes to pipelines because -latest doesn't mean latest

The correct way is to use dotnet installation task (ADO | GHA) and not rely on specific bits installed on the host as much as possible.

[stap123]

It takes time to work out all the quirks of new software when it's released to not break environment. Switching over to windows-2022 on day 0 would break a lot of pipelines/workflows as well as it would require for GHA team to have it available on that time in Azure environment. I'll admit it is my fault that I didn't put * with clarification that latest OS requires additional work, thorough testing and customer feedback before it can be released "in the wild" and all that combined takes time. What I originally meant by GA is GA in sense of OS vendor and GitHub Actions.

Totally understand it takes time to ensure everything works it was more an observation of the fact that -latest implies a little risk because you're asking for the latest 😃 Thanks for the clarification though.

The correct way is to use dotnet installation task (ADO | GHA) and not rely on specific bits installed on the host as much as possible.

That's a fair point, on the flip side would it not make sense to have no .NET versions available on the image by default so that it's not possible for people to do it wrong? This would force people down the happy path when creating pipelines.

Keep up the good work 🍾

[MarcoWesterink]

@neman 6.0 is bundled in VS2022, so it's available on the image but not installed via part of .NET installation script

Still might be good to add to the table. It confused me too.

[catthehacker]

That's a fair point, on the flip side would it not make sense to have no .NET versions available on the image by default so that it's not possible for people to do it wrong? This would force people down the happy path when creating pipelines.

Some versions of software that can be installed through actions/setup-* is kept in the image because of popularity (of version and not only) and (not sure if all since I didn't check all actions but) setup-* tasks will match against requested version and if it matches, it will skip installation (e.g. task requires version '5.0.x', '5.0.100' is installed - skips installation). I also don't want to speak as something given due to the fact I'm just a random contributor, so it's better to take GH Actions team words for mine but I do remember .NET being nightmare to maintain due to various issues (like installation time which I tried to help mitigate but for Ubuntu, ref: #2367).

Totally understand it takes time to ensure everything works it was more an observation of the fact that -latest implies a little risk because you're asking for the latest

Another possible option would be to

use windows-current, it doesn't imply any (in)stability and/or version of software installed on the runner
although, I'm sure if that was or were to be used as the name it would confuse new/old users "why it's not latest anymore" and some could find current as inadequate choice of word for the tag (somehow), nature of language and conveying message in as few words as possible

[stap123]

use windows-current, it doesn't imply any (in)stability and/or version of software installed on the runner although, I'm sure if that was or were to be used as the name it would confuse new/old users "why it's not latest anymore" and some could find current as inadequate choice of word for the tag (somehow), nature of language and conveying message in as few words as possible

Naming is hard for sure 🤣

[miketimofeev]

@jozefizso the message has been disabled.

[donatellijl]

It seems that windows-latest is still pointing to windows-2019 instead of windows-2022. When I run my pipeline in Azure DevOps with the vmImage set to windows-latest, I see that the pool is set to windows-2019.

When I change to windows-2022, the pool is set to windows-2022.

According to the docs, windows-latest should be windows-2022.

I'm also confused as to why the docs say that for classic pipelines, the default is windows-2019. Shouldn't it be windows-latest?

[al-cheb]

@donatellijl, Could you check?

pool:
  name: Azure Pipelines
  vmImage: windows-latest

[donatellijl]

@donatellijl, Could you check?

pool:
  name: Azure Pipelines
  vmImage: windows-latest

I added "name: Azure Pipelines" and now instead of my first screenshot, I see windows-latest as the Image. Why is having the name a requirement?

[princekumarLnG]

Hello everyone, I hope you all are well.
I was trying to create a database with Microsoft hosted agent in yml pipeline. Can anyone please tell me if these agents offers any database server? This will be a great help 👍

[timheuer]

Hello everyone, I hope you all are well. I was trying to create a database with Microsoft hosted agent in yml pipeline. Can anyone please tell me if these agents offers any database server? This will be a great help 👍

Complete list of software is available at the image definitions: https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md (for windows-latest)