search

actions / runner-images

GitHub Actions runner images
MIT License
9.22k stars 2.86k 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

miketimofeev commented 2 years ago

New announcement is here https://github.com/actions/virtual-environments/issues/5403

sachinbdoshi commented 2 years ago

Well I just closed a case with Microsoft where they confirmed that Agent Pool with vs2017-2016 will be supported until June-2022 and here this article is saying it is being deprecated in April 2022. what is the real truth ? today we received the Windows 2016 brownout error in our build pipeline which is building win 2016 container images.

link to where microsoft updated the information that they will deprecate the agent pools with vs2017-2016 in June 2022. https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml#software

Croydon commented 2 years ago

@sachinbdoshi https://github.com/actions/virtual-environments/issues/5238#issuecomment-1098836733

gene-keys commented 2 years ago

IMPORTANT NOTE FOR THOSE OF YOU STILL STRUGGLING WITH WIN2016 BROWNOUT NOTICE.

CHECK EVERYTHING!

NOT JUST YOUR PIPELINE CODE, CHECK PIPELINE TRIGGERS POOLS. CHECK RELEASES POOLS, CHECK ALL THE POOLS EVERYWHERE ON YOUR DEVOPS ACCOUNT. WHAT WILL HAPPEN IS YOU WILL EVENTUALLY FIND SOMETHING STILL SET TO USE WIN2016 POOL. ONCE YOU FIND ALL OF THEM YOUR ACCOUNT WILL NO LONGER GET THE BROWNOUT NOTICE EVEN DURING THE SCHEDULED TIMES. SO IF YOU ARE GETTING THE NOTICE ITS NOT YOUR WIN2017 POOL, OR WIN-LATEST IN THE YML, ITS SOMETHING ELSE,

AZURE NOTICES ARE DOING A TERRIBLE JOB ON THIS WITH THEIR WORDING AND WHERE THE NOTICE APPEARS. THE NOTICE MEANS YOUR AZURE DEVOPS ACCOUNT IS STILL USING WINDWOS POOL SOMEWHERE, YOU DID NOT CHECK EVEYWHERE.

eli-schwartz commented 2 years ago

New announcement is here #5403

I'm still getting brownout cancellations on Azure, which... mention April 1 (confusing) and link to this ticket, As a small UX thing, this should probably update the message text.

The exact job where I saw this is here: https://dev.azure.com/jussi0947/jussi/_build/results?buildId=14019&view=logs&j=e635d226-97b8-55eb-2970-00a63a10ba8b

miketimofeev commented 2 years ago

@eli-schwartz sorry, we will change the message during the next brownout

eli-schwartz commented 2 years ago

BTW the message is still the old one :) seen today in https://dev.azure.com/jussi0947/jussi/_build/results?buildId=14088&view=logs&j=678c5357-36f0-50cc-b96e-1a6f7149eed2

todd-fraser commented 2 years ago

@eli-schwartz @miketimofeev is there anywhere I can find when this brownout will be over? The only dates I've found listed out specifically are for previous dates. I was asked to deploy after hours and now I'm getting this deprecation message I'm not able to fix tonight. Oops.

eli-schwartz commented 2 years ago

@todd-fraser the new brownout dates are listed at #5403 and hopefully for the next brownout we will get links pointing there instead. :)

todd-fraser commented 2 years ago

@eli-schwartz Thanks much! I'll keep working to change the agent tonight. Not my expertise exactly. Only deploying to Prod, what could possibly go wrong?

eli-schwartz commented 2 years ago

I dunno :) for my part, the CI for a build system just fails to test whether it correctly generates VS solution files for the windows-2016 environment (technically, for vs2017, but I think windows-2016 is the only image that has vs2017 installed) so it's a bit questionable whether we should remove those jobs at all.

In the meantime we simply ignore these cancellations. At some point we'll probably switch some jobs over to vs2019 and pray that no users still have vs2017 installed (or that we don't regress for it due to lack of test coverage).

What can go wrong? We could completely fail to generate solution files for an outdated toolchain that no one should use. :laughing:

Ziya137200 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

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

Mitigation ways

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

Duplicate of #

Kalmuraee commented 2 years ago

My issue is on deployment of the release in azure, I have no idea how to change that to windows-latest.