search

actions / runner-images

GitHub Actions runner images
MIT License
9.17k stars 2.84k forks source link

Windows-2016 environment will be removed on March 15, 2022 #4312

Closed miketimofeev closed 2 years ago

miketimofeev commented 2 years ago

Breaking changes

Windows 2016 hosted runners will be removed from GitHub actions and Azure DevOps. To raise awareness of the upcoming removal, we will temporarily fail jobs using Windows 2016 for two short 'brownout' periods. Builds that are scheduled to run during the brownout periods will fail. The brownouts are scheduled for the following dates and times:

GitHub Actions:

Azure DevOps

Target date

March 15, 2022

The motivation for the changes

Windows Server 2016 Active support ends on 11 Jan 2022 and Windows Server 2022 VM image is going out of beta later this year. As part of our ongoing efforts to keep GitHub and Azure Devops hosted runners updated and secure, the Windows 2016 virtual environment will be removed from GitHub Actions and Azure DevOps.

Possible impact

If your project depends on Windows 2016 environment and visual studio 2017 it can be broken.

Virtual environments affected

Mitigation ways

We recommend you change jobs using runs-on: windows-2016 to use runs-on: windows-latest which will ensure you're always running on the latest version of Windows Server.

If you need to pin your job to a specific version of Windows Server, you can see the full list of supported versions here https://github.com/actions/virtual-environments#available-environments

IanKemp commented 2 years ago

Windows Server 2016 Active support ends on 11 Jan 2022 and we are Windows Server 2022 VM image is going out of beta later this year.

This sentence makes no grammatical sense and as such I have no idea what it is trying to say. Please do basic proofreading before you post something that the entire world is likely to see.

miketimofeev commented 2 years ago

@IanKemp thanks, fixed

CrisBuda commented 2 years ago

It's great that I got this notification right there in the Azure DevOps Release Definition. I can easily change the agent, however, I don't have an option for Windows-latest in the dropdown. The only other two windows ones are windows-2019 and windows-2022. Can I choose windows-2022 and assume it will be supported for a few years?

miketimofeev commented 2 years ago

@CrisBuda sure thing! Both windows-2019 and windows-2022 will be supported for a few years. windows-latest is available using yml definitions and currently points to windows-2019 image as 2022 is in the beta state.

CrisBuda commented 2 years ago

@CrisBuda sure thing! Both windows-2019 and windows-2022 will be supported for a few years. windows-latest is available using yml definitions and currently points to windows-2019 image as 2022 is in the beta state.

Thanks for clearing that up. windows-2022 doesn't mention it is in beta in the dropdown. I will choose windows-2019

markybry commented 2 years ago

I haven't specified runs-on anywhere and I am still seeing this warning and can't see where to specify it. Is it as simple as adding the following to my azure-pipelines.yml file as per https://docs.microsoft.com/en-us/azure/devops/pipelines/customize-pipeline?view=azure-devops

pool: vmImage: "ubuntu-latest"

or

pool: vmImage: "windows-latest"

miketimofeev commented 2 years ago

@markybry yes, it is that simple. Classic pipelines editor sets windows-2016 VM image by default, but this will be changed in the nearest future.

Croydon commented 2 years ago

I have no problem saying goodbye to Windows Server 2016, but dropping Visual Studio 2017 is kinda hurtful. Not all projects can use up-to-date tooling

IanKemp commented 2 years ago

I have no problem saying goodbye to Windows Server 2016, but dropping Visual Studio 2017 is kinda hurtful. Not all projects can use up-to-date tooling

Visual Studio 2017 is half a decade old at this point, which is an epoch in software development. If your project depends on VS2017 maybe, just maybe, it's time to figure out an upgrade path.

markybry commented 2 years ago

@markybry yes, it is that simple. Classic pipelines editor sets windows-2016 VM image by default, but this will be changed in the nearest future.

Seems that when no vm image is specified that any VM available at that time is selected which may then cause this error.

miketimofeev commented 2 years ago

@markybry the recommended approach is to target a specific image that suits your needs

valx commented 2 years ago

We are using Azure DevOps to deploy resources from an ARM template. In particular in Azure DevOps Release Pipelines, we use an "ARM template deployment" task (latest version: 3.*). When the release is executed we get a warning: <<The windows-2016 environment will be deprecated on November 15, 2021, and removed on March 15, 2022. Migrate to windows-latest instead. For more details see https://github.com/actions/virtual-environments/issues/4312 >> As a developer using the Microsoft 'pre-packaged' task, I cannot configure the underlying Windows version. So is the task going to be modified accordingly to use a newer version of Windows or is an alternative going to be offered to deploy ARM templates in Azure Devops Releases?

miketimofeev commented 2 years ago

@valx the agent can be configured for the releases as well: image

kipwoker commented 2 years ago

I have no problem saying goodbye to Windows Server 2016, but dropping Visual Studio 2017 is kinda hurtful. Not all projects can use up-to-date tooling

I have the same issue. Is it possible to have VS2017 at windows-2019? It could be a solution for me. We have a bunch of .net 4.6.2 apps that are impossible to upgrade before March.

IanKemp commented 2 years ago

I have no problem saying goodbye to Windows Server 2016, but dropping Visual Studio 2017 is kinda hurtful. Not all projects can use up-to-date tooling

I have the same issue. Is it possible to have VS2017 at windows-2019? It could be a solution for me. We have a bunch of .net 4.6.2 apps that are impossible to upgrade before March.

No, Microsoft isn't going to waste time and effort catering to businesses that haven't bothered to invest the time and effort to keep their software current.

brandonh6k commented 2 years ago

You should be able to use the Windows 2019 image (it includes VS 2019 and .NET 4.7.2) or the Windows 2022 image (includes VS 2022 and .NET 4.8) with minimal changes to your apps. Hosted Agents

Otherwise, you can always use a self-hosted agent with whatever mix of software and versions that you need until you can upgrade to something like 4.8.

kipwoker commented 2 years ago

No, Microsoft isn't going to waste time and effort catering to businesses that haven't bothered to invest the time and effort to keep their software current.

I've got your point, but:

  1. GitHub Actions isn't a free service. It costs money
  2. I'm not proposing to keep the old version forever. There is less than half a year for making changes. I'm trying to propose something that will give us more time to upgrade the solutions
kipwoker commented 2 years ago

@brandonh6k thank you for the answer. Upgrade or self-hosted agent could be an option.

Sergey-Nosov-CloudFit commented 2 years ago

windows-latest is not available in Release pipelines. Please add Release_Agents :

LennardF1989 commented 2 years ago

windows-latest is not available in Release pipelines. Please add Release_Agents :

Can confirm, not available under release pipelines.

frederikolsen88 commented 2 years ago

I'm currently using windows-2016 for certain tasks where I need to use bcputil to move data between databases.

However, as far as I was able to tell when I set up my pipelines, bcputil is not present in windows-2019, which would make migration impossible for me.

Has the utility been included in any of the later images?

al-cheb commented 2 years ago

I'm currently using windows-2016 for certain tasks where I need to use bcputil to move data between databases.

However, as far as I was able to tell when I set up my pipelines, bcputil is not present in windows-2019, which would make migration impossible for me.

Has the utility been included in any of the later images?

@frederikolsen88 , bcp util is already pre-installed on Windows Server 2019: image

frederikolsen88 commented 2 years ago

@al-cheb Excellent! I thought there might be a chance that I was just looking in the wrong place. Thank you very much!

v-dineshdeva commented 2 years ago

Iam not able to see any "Agent Specification" section. How do I get that added?

image

miketimofeev commented 2 years ago

@v-dineshdeva Hey! I assume you have the same issue as described here https://github.com/actions/virtual-environments/issues/4464

djohnson864 commented 2 years ago

I already have in the yaml file.

pool: vmImage: 'windows-latest'

But still got the warning. Any ideas?

miketimofeev commented 2 years ago

@v-dineshdeva there was an issue on the AzureDevOps side, which is resolved by now

miketimofeev commented 2 years ago

@djohnson864 does your build run on windows-2019? You can check it in the Initialize job step image

arambazamba commented 2 years ago

Some of the az-400 classroom moc labs depend on this agent and VS 2017 ... wont build with win19 or win22 ... best would be to update the labs from "old" .net ... Examples: https://github.com/MicrosoftLearning/AZ400-DesigningandImplementingMicrosoftDevOpsSolutions/blob/master/Instructions/Labs/AZ400_M11_Setting_Up_and_Running_Functional_Tests.md

miketimofeev commented 2 years ago

@arambazamba thanks for the heads-up! Could you create an issue about that in the https://github.com/MicrosoftLearning, please?

yogeshkoshti4313 commented 2 years ago

I'm using vs2017-win2016 and everything is working fine but as a part of this deprecation I've tried to use both windows-2019 and windows-2022 but after successful deployment, my App Service has started throwing package exceptions. I'm not sure what needs to do here to fix this issue?

Does anyone face this kind of issue after migration to the latest run agent?

takacs525 commented 2 years ago

Thanks for the notification. I would like to know more about this 'brownout' periods. Question: If a pipeline starts running just before one of the planned 'brownout' periods, will it continue to work during that interval or will be terminated?

miketimofeev commented 2 years ago

@takacs525 no, only the new one will fail.

nirbheek commented 2 years ago

Visual Studio 2017 is half a decade old at this point, which is an epoch in software development. If your project depends on VS2017 maybe, just maybe, it's time to figure out an upgrade path.

We want to be able to test with Visual Studio 2017, since users will be using it. What image provides that? windows-2019 provides VS 2019.

dixyes commented 2 years ago

The question is windows-2019 image only provides Visual Studio 2019 build tools, vs15 build tools can be installed in vs16, but it's not...

PHP 7.4 is still offically supported until the end of 2022, see https://www.php.net/supported-versions.php, it's built with vs15, that's meaning all php 7.4 windows extensions cannot be tested on hosted runners in next year.

Maybe should I forget actions then turn to self-managed buildbot?

rvanmil commented 2 years ago

I have no problem saying goodbye to Windows Server 2016, but dropping Visual Studio 2017 is kinda hurtful. Not all projects can use up-to-date tooling

@Croydon Not sure if this is of any help to you, but I was able to switch to windows-latest by adding the following step to my workflow (this was for a cordova-windows project):

- name: Install Visual Studio 2017
  run: |
    choco install visualstudio2017community
    choco install visualstudio2017-workload-universal

And adding the following env to the step using Visual Studio 2017

env:
  MSBUILDDIR: "/C/Program Files (x86)/Microsoft Visual Studio/2017/Community/MSBuild/15.0/Bin"
Croydon commented 2 years ago

@rvanmil How long does it take to install it? The last time I tried something like that it took 40+ minutes which was too much for our use case

rvanmil commented 2 years ago

Here's the latest build log. It appears windows-latest currently uses Microsoft Windows Server 2019. Installing Visual Studio 2017 with choco took less than 10 minutes.

image
skoladich commented 2 years ago

Can you please stop discontinuing environments in DevOps pipelines that are the default setting?

I didn't choose vs2017-win2016 as my agent specification, that's been the default since I started working with pipelines and it's still the default when I go to create a new release pipeline! I have to manually change this in hundreds of pipelines - unlike the build pipeline change with discontinuing Ubuntu, this setting doesn't appear to be available through the az devops CLI extension or the REST API. Why isn't windows-latest the default if you're going to keep discontinuing specific versions?

FH-Inway commented 2 years ago

The announcement says a brownout took place on December 1, 2021 4:00pm UTC – 10:00pm UTC. We did not notice this. However, the announcement in our Azure DevOps pipelines states the following:

[warning]A brownout will take place on December, 15 3:00 PM - 4:30 PM UTC to raise awareness of the upcoming windows-2016 environment removal. For more details, see https://github.com/actions/virtual-environments/issues/4312

Are we right to assume that the announcement in this issue is missing a "5", i.e. there will be a brownout next week on December 15?

miketimofeev commented 2 years ago

@FH-Inway sorry for the inconvenience. Brownouts for ADO have a different schedule https://docs.microsoft.com/en-us/azure/devops/release-notes/2021/sprint-196-update#brownout-schedule

miketimofeev commented 2 years ago

@FH-Inway we will take a look as new build pipelines where switched to windows-latest, but it seems that it should be done for releases as well

takluyver commented 2 years ago

~I don't suppose there's any straightforward way to cache the installation of Visual Studio 2017? An extra 10 minutes (per this comment) on every Windows CI build would be fairly painful.~

Nevermind, it appears that VS 2019 will work for us. :slightly_smiling_face:

gioexp commented 2 years ago

Please, could you avoid to change burnout dates every week? This is soo bad....

miketimofeev commented 2 years ago

@gioexp The dates mentioned in the initial posts are the final ones, sorry for the inconvenience.

natelaff commented 2 years ago

I'm seeing this warning but from what I can see my pipelines do not use Windows-2016. Am I supposed to be seeing these warnings in this case, or am I still dependent on it somewhere that I can't find?

miketimofeev commented 2 years ago

@natelaff it looks like you have some jobs run on windows-2016 as the warning is not shown for all the others.

HVNunoM commented 2 years ago

@miketimofeev if i have a pipeline where the agent job specifies "vs2017-win2016" after that image is removed what will happen to the pipeline? will it always fail, till i change the option to a newer version and save it?

miketimofeev commented 2 years ago

@HVNunoM correct, it will always fail

HVNunoM commented 2 years ago

@HVNunoM correct, it will always fail

Thanks for the answer. I just wanted to know that it will not change somehow automatically, so that i change pipelines previously and test them. Because let's suppose that in the "Releases" section of azure devops i click on "Create release" with what you are saying i will be able to create the release but then only when running it will fail because that agent image doesn't exist anymore. Or probably microsoft will not let me create the release which i think would make more sense in this case.