search

actions / runner-images

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

Windows-2016 environment removal postponed until April 1st, 2022 #5238

Closed alepauly closed 2 years ago

alepauly commented 2 years ago

Breaking changes

Windows 2016 hosted runners were scheduled for full removal on March 15th, 2022. However, we are still seeing significant usage from customers and we want to give them more time to migrate to the new runners. In order to give customers another chance to move to either windows-2019 or windows-2022 we will delay the removal of windows-2016 until April 1st, 2022.

To raise awareness of the removal, we will have rolling 12-hour periods where the image will be unavailable for customers. During these "brownout" periods, customers will see an error message indicating that the image is slated for removal on April 1st, 2022. The schedule for those brownout periods is as follows for both Azure DevOps and GitHub Actions:

  1. Tuesday March 15, 20:00 UTC to March 16, 08:00 UTC
  2. Thursday March 17, 08:00 UTC to March 17, 20:00 UTC
  3. Friday March 18, 20:00 UTC to March 19, 08:00 UTC
  4. Monday March 21, 08:00 UTC to March 21, 20:00 UTC
  5. Tuesday March 22, 20:00 UTC to March 23, 08:00 UTC
  6. Wednesday March 23, 20:00 UTC to March 24, 08:00 UTC
  7. Friday March 25, 08:00 UTC to March 25, 20:00 UTC
  8. Sunday March 27, 20:00 UTC to March 28, 08:00 UTC
  9. Tuesday March 29 Wednesday March 30, 08:00 UTC to March 30, 20:00 UTC
  10. Full removal - April 1, 15:00 UTC

See the original announcement at #4312

Target date

April 1st, 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

Workflows targeting the Windows 2016 image will fail.

Virtual environments affected

Mitigation ways

Change your workflows to use windows-latest, windows-2022, or windows-2019

rdhaundiyal commented 2 years ago

Hi, I am not using windows-2022 but still getting the error related to 2016 is it some side effect

[Error 1]

This is a scheduled windows-2016 brownout. The windows-2016 environment is deprecated and will be removed on April 1st, 2022. For more details, see https://github.com/actions/virtual-environments/issues/5238

[Error 2]

The remote provider was unable to process the request.

Deployment canceled by Microsoft.VisualStudio.Services.ReleaseManagement on 3/16/2022, 6:15 PM

GokulKannanN commented 2 years ago

We are using vmImageName: 'ubuntu-latest' but still we are getting this error. what is the solution for this issue.

rdhaundiyal commented 2 years ago

update, it was the release agent which was by default picking up 2016-17 even after creating a new release from scratch, settign it manually to 2022 worked

GokulKannanN commented 2 years ago

worked

I did not understand. Can you please tell me where I have to update 2022. because Ubuntu does not have 2022, its latest version is 20.04

rdhaundiyal commented 2 years ago

my issue was related to release , in the release pipeline -> edit, you have agent, clicking on the agent show you the provider https://blog.novacare.no/devops-change-agent-specification-to-windows-latest/

ManaliMnS commented 2 years ago

worked

I did not understand. Can you please tell me where I have to update 2022. because Ubuntu does not have 2022, its latest version is 20.04

Go to your release pipeline. Edit . Go to agent job. Change agent specification to windows latest

CodeIn24 commented 2 years ago

Hi, Just for better understanding, we have self-hosted agent on one of our machines having windows 2016 OS , so this means we have to upgrade the OS and re-host the agent for pipelines to keep running, am I missing anything?

This option will not work for us considering our setup: image

alepauly commented 2 years ago

Hi, Just for better understanding, we have self-hosted agent on one of our machines having windows 2016 OS , so this means we have to upgrade the OS and re-host the agent for pipelines to keep running, am I missing anything?

@CodeIn24 - this doesn't affect self-hosted agents. it's only related to the hosted Windows 2016 virtual environment. You don't need to change anything.

CodeIn24 commented 2 years ago

@alepauly good to know this, thanks

Razakhel commented 2 years ago

Hello,

As is the custom with MSVC, the SDK currently available on the windows-2019 image is broken and does not compile:

C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(502,17): error C2059: syntax error: '/'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(530,17): error C2059: syntax error: '}'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(531,13): error C2059: syntax error: '}'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(533,9): error C2059: syntax error: '}'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(534,5): error C2059: syntax error: '}'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(665,16): error C2079: 'varDefaultValue' uses undefined struct 'tagVARIANT'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(950,16): error C2079: 'varValue' uses undefined struct 'tagVARIANT'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\propidlbase.h(319,24): error C2059: syntax error: '/'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\propidlbase.h(378,37): error C2371: 'pvarVal': redefinition; different basic types
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\oaidl.h(510): message : see declaration of 'pvarVal'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\propidlbase.h(379,9): error C2059: syntax error: '}'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\propidlbase.h(380,5): error C2059: syntax error: '}'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\propidlbase.h(383,3): error C2059: syntax error: '}'
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\propidlbase.h(384,1): error C2059: syntax error: '}'

I did file a report on this a couple months ago in anticipation, but I guess many users will simply not be able to upgrade the version because of this. Using the windows-2022 image & VS 2022 works fine for me, but may not be suitable for others. Please either update the SDK or explicitly state that the 2019 image cannot be used for C & C++ users, so they can safely migrate to 2019 or 2022.

Thank you!

toddbellamy commented 2 years ago

We are getting the windows-2016 brownout error even though our Pipeline is using windows-latest and the log even shows that windows-2022 agent was used. Why?

jackweldon commented 2 years ago

@oddbellamy try vmImageName: 'windows-2019'

slobshay commented 2 years ago

Hello, according to brownout plan, there shouldn't be anything now (20.3.2022), although our build failed with brownout message. Can anyone please assist?

eeropenttinen commented 2 years ago

Hello, according to brownout plan, there shouldn't be anything now (20.3.2022), although our build failed with brownout message. Can anyone please assist?

I have exactly the same issue and using windows-2022 which should be working fine.

eeropenttinen commented 2 years ago

We are getting the windows-2016 brownout error even though our Pipeline is using windows-latest and the log even shows that windows-2022 agent was used. Why?

I have exactly the same isssue.

tabenari commented 2 years ago

We had the same issue Fixed by changing the agent specification for our jobs to windows-latest as suggested in the description:

image

dduleep commented 2 years ago

we have 1000 classic pipelines with vs2017-win2016 agent, we are planning to migrate all pipelines to windows-2019, looking for an easy update, instead of GUI, any options do we have to update of classic pipeline agent? API or CLI option?

geekzter commented 2 years ago

We are getting the windows-2016 brownout error even though our Pipeline is using windows-latest and the log even shows that windows-2022 agent was used. Why?

That should not be happening. Is this a UI of YAML pipeline? Are you referencing a pool name? If so which pool?

geekzter commented 2 years ago

we have 1000 classic pipelines with vs2017-win2016 agent, we are planning to migrate all pipelines to windows-2019, looking for an easy update, instead of GUI, any options do we have to update of classic pipeline agent? API or CLI option?

You can use the REST API to update classic / UI pipelines.

slobshay commented 2 years ago

We are getting the windows-2016 brownout error even though our Pipeline is using windows-latest and the log even shows that windows-2022 agent was used. Why?

That should not be happening. Is this a UI of YAML pipeline? Are you referencing a pool name? If so which pool?

Not anymore, but trust me, it didn't even start to run. We moved our builds to use windows-2019, all good now.

SandeepChava91 commented 2 years ago

We are getting the below error when trying to mitigate by running on the windows-latest image. We currently, use vs2017-win2016.

[error]System.Management.Automation.CmdletInvocationException: Unable to determine the location of vstest.console.exe ---> System.IO.FileNotFoundException: Unable to determine the location of vstest.console.exe

Can anyone assist here?

eeropenttinen commented 2 years ago

In our case the build works fine (using windows-2022 agent), but deployment to cloud of the web app fails when the pipeline is trying to publish it Azure.

steps:
- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  inputs:
    PathtoPublish: build

Behind the scenes, it seems it is using something for deployments, windows-2016. I don't know where to change that though.

I can see from logs: "Deployment canceled by Microsoft.VisualStudio.Services.ReleaseManagement"

geekzter commented 2 years ago

In our case the build works fine (using windows-2022 agent), but deployment to cloud of the web app fails when the pipeline is trying to publish it Azure.

steps:
- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  inputs:
    PathtoPublish: build

Behind the scenes, it seems it is using something for deployments, windows-2016. I don't know where to change that though.

I can see from logs: "Deployment canceled by Microsoft.VisualStudio.Services.ReleaseManagement"

Is this a release pipeline? If so, this could apply.

FawadBhatti-Experian commented 2 years ago

Our application runs on Azure Cloud (Classic) and trying to upgrade the pipeline to accomodate new changes but after updating the vmImage to windows-2019 or windows-2022 also msbuild version from 15.0 to 16.0 deployment gets failed.

I would really appreciate if someone help me to fix the issue.

HolisticDeveloper commented 2 years ago

we will delay the removal of windows-2016 until April 1st, 2021.

@alepauly please note your typo in the first paragraph -- should be 2022 instead of 2021.

alepauly commented 2 years ago

we will delay the removal of windows-2016 until April 1st, 2021.

@alepauly please note your typo in the first paragraph -- should be 2022 instead of 2021.

Thank you @HolisticDeveloper! Fixed.

peternznguyen commented 2 years ago

We are using Azure DevOps to build and manage for source code and SSIS packages for Data Warehouse system. Below are the settings that worked fine for vs2019-win2016 image and then changed to Windows-2019 image and failed for SSIS.

I. Fine working setttings

Our current pipeline is configured to run Agent job including

The YAML file 

pool:
  name: Azure Pipelines
  demands: msbuild

steps:
- task: MSBuild@1
  displayName: 'Build database projects **/*.sqlproj'
  inputs:
    solution: '**/*.sqlproj'
  condition: succeededOrFailed()

- task: TG.VSTS-SSIS.BuildSSIS-task.BuildSSIS@1
  displayName: 'Build SSIS '
  inputs:
    solnPath: '$/Data Warehouse/odl.datawarehouse/odl.datawarehouse.sln'
    solnConfigName: Development
    projPath: '$/Data Warehouse/odl.datawarehouse/IntegrationServices/DWFrameworkSSIS/DWFrameworkSSIS.dtproj'
    projConfigName: Development
    cmdSwitch: build
    devenvVersion: VS2017ent

- task: CopyFiles@2
  displayName: 'Copy Files to: $(Build.ArtifactStagingDirectory)'
  inputs:
    SourceFolder: '$/Data Warehouse/odl.datawarehouse'
    TargetFolder: '$(Build.ArtifactStagingDirectory)'

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'

However, lately I was warned as below

##[warning]The windows-2016 environment is deprecated and will be removed on April 1st, 2022. For more details, see https://github.com/actions/virtual-environments/issues/5238
Pool: Azure Pipelines
Image: vs2017-win2016
Agent: Hosted Agent

Above warnings mean currently we are running VS2017 on Azure Virtual Machine with Windows 2016

II. Changed as warning and SSIS failed

Following the link https://github.com/actions/virtual-environments/issues/5238, I changed workflows to use windows-2019 (new Image replaced "vs2017-win2016", not changed SSIS settings) for the pineline, as a result:

I have searched to try solving the issue "Devenv.com not found" but not any help

Can you guys please help me to fix this as the deprecated date for Win-2016 is coming soon?

Much appreciated!

Peter

Munira-Panjwani commented 2 years ago

Hi,

I have updated the yml (below) image image

But its failing with the error of: image

Help is much appreciated.

Munira

nha-vertica commented 2 years ago

Regardless of change of Agent Specification Win2019, 2022 or Win-Latest - still getting the brownout which cancels the whole thing regardless of being outside of brownout period

Current time: UTC 06:50 (March 28)

"Friday March 25, 08:00 UTC to March 25, 20:00 UTC Sunday March 28, 20:00 UTC to March 29, 08:00 UTC Tuesday March 30, 08:00 UTC to March 30, 20:00 UTC"

geekzter commented 2 years ago

Hi,

I have updated the yml (below) image image

But its failing with the error of: image

Help is much appreciated.

Munira

You should use 'Azure Pipelines' as pool name instead of 'Hosted VS2017'

geekzter commented 2 years ago

Regardless of change of Agent Specification Win2019, 2022 or Win-Latest - still getting the brownout which cancels the whole thing regardless of being outside of brownout period

Current time: UTC 06:50 (March 28)

"Friday March 25, 08:00 UTC to March 25, 20:00 UTC Sunday March 28, 20:00 UTC to March 29, 08:00 UTC Tuesday March 30, 08:00 UTC to March 30, 20:00 UTC"

What pool name are you using?

nha-vertica commented 2 years ago

Regardless of change of Agent Specification Win2019, 2022 or Win-Latest - still getting the brownout which cancels the whole thing regardless of being outside of brownout period Current time: UTC 06:50 (March 28) "Friday March 25, 08:00 UTC to March 25, 20:00 UTC Sunday March 28, 20:00 UTC to March 29, 08:00 UTC Tuesday March 30, 08:00 UTC to March 30, 20:00 UTC"

What pool name are you using?

It works now :)

We have been digging into this and the Agent was set to Win2019, but under the Init Job Task it was running as Win2016 regardless of our changes to the agent - but for some reason it works now, my colleague got a change registered with a change of AgentSpec -> identifier (null -> Windows-2019)

I made several changes but for some reason they were not kicked in even though revisiting the page showed the last windows version I chose.

What happened we don't actually know as he did the same as I did, but maybe something else were wrong in our case. But the brownout shouldn't have happened anyway, but somewhat good as we thought we had it in order in the first place.

miketimofeev commented 2 years ago

Upd: The latest brownout is shifted to Wednesday, March 30, 08:00 UTC —20:00 UTC

Munira-Panjwani commented 2 years ago

Hi, I have updated the yml (below) image image But its failing with the error of: image Help is much appreciated. Munira

You should use 'Azure Pipelines' as pool name instead of 'Hosted VS2017'

It worked now :)

I completely removed Hosted 2017 and its taking the latest now, so Build started working

For release deployment, I changed on the Run Agent of every step

MMThornberg commented 2 years ago

Getting this today despite brownout should not occur today - see OP:

"This is a scheduled windows-2016 brownout. The windows-2016 environment is deprecated and will be removed on April 1st, 2022. For more details, see https://github.com/actions/virtual-environments/issues/5238"

teeto commented 2 years ago

Still getting the error, this is the conf in my yml file:

pool: name: 'Azure Pipelines' vmImage: 'windows-latest'

In the logs i see is using the hosted agent, could it be the problem?

teeto commented 2 years ago

Now it works, it has nothing to do with the yml file, its set in the release pipeline config:

image

peternznguyen commented 2 years ago

Hi, Select Windows-Latest but image but error C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1220,5): Error MSB3644: The reference assemblies for .NETFramework,Version=v4.5 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks

.NETFramework,Version=v4.8 already install on Azure Virtual Machine Win-2016 image

Any help much appreciated

wildhart commented 2 years ago

I'm getting this brownout but I'm outside your published brownout schedule:

image

image

I'm just trying to deploy a quick hotfix using the same agent as the previous deployment...

aroonk1982 commented 2 years ago

I have tried using each of the below vmImages but still get the Brownout error ubuntu-latest windows-latest windows 2019

Also tried adding 'Azure Pipelines' as the pool name, but still the same error.

image

Munira-Panjwani commented 2 years ago

I have tried using each of the below vmImages but still get the Brownout error ubuntu-latest windows-latest windows 2019

Also tried adding 'Azure Pipelines' as the pool name, but still the same error.

image

Try removing the "Azure Pipelines". That worked for me

aroonk1982 commented 2 years ago

I have tried using each of the below vmImages but still get the Brownout error ubuntu-latest windows-latest windows 2019 Also tried adding 'Azure Pipelines' as the pool name, but still the same error. image

Try removing the "Azure Pipelines". That worked for me

Still the same error

sebastianrogers commented 2 years ago

I had the same issue with 

pool:
  name: Hosted
  vmImage: 'windows-latest'

Resolved it by removing name: Hosted

pool:
  vmImage: 'windows-latest'
ghost commented 2 years ago

I understand this will affect Workflows (Pipelines, Releases...). Will this affect Apps already deployed and running on Azure that were deployed with Windows-2016 Builds and Releases?

geekzter commented 2 years ago

No, but it will affect your ability to-rebuild and re-deploy them.

manishvsuryawanshi commented 2 years ago

HI, once we updated to latest version 2022, what steps needs to perform with .net code which shows below issue in CI pipeline:

[error]C:\Users\VssAdministrator.nuget\packages\microsoft.net.sdk.functions\1.0.24\build\netstandard1.0\Microsoft.NET.Sdk.Functions.Build.targets(41,5): Error : It was not possible to find any compatible framework version

The framework 'Microsoft.NETCore.App', version '2.1.0' was not found.

jsoref commented 2 years ago

Could someone please reword this message:

The Windows 2016 environment is deprecated, consider switching to the recent Windows environment version. For more details, see https://github.com/actions/virtual-environments/issues/4312

the recent Windows environment version is really grammatically awkward.

Possible fixes:

miketimofeev commented 2 years ago

Windows-2016 is not available anymore in GitHub actions as it was announced. For ADO the retirement date has been shifted. We will update the issue once the exact date is known.

MelchiorBrandtCorstiusAtABNAMRO commented 2 years ago

Windows-2016 is not available anymore in GitHub actions as it was announced. For ADO the retirement date has been shifted. We will update the issue once the exact date is known.

Any news on a new decom date for ADO Win2016 agents? We spend a lot of effort trying to get teams/pipelines away from Win2016 agents, but since it is still up and running we unfortunately see an increase of people in our company 'accidentally' using it again.

miketimofeev commented 2 years ago

@melchiorbc the current proposal is June, 30. We will announce it soon.