search

actions / runner-images

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

macOS-latest workflows will use macOS-11 #4060

Closed miketimofeev closed 2 years ago

miketimofeev commented 2 years ago

Breaking changes

macOS-11 is ready to be the default version for the "macos-latest" label in GitHub Actions and Azure DevOps.

Target date

This change will be rolled out over a period of several weeks beginning on September, 15. We plan to complete the migration by November, 3 December, 13 January 14.

The motivation for the changes

GitHub Actions and Azure DevOps have supported macOS-11 in preview mode since October 2020, and starting from August 2021 macOS-11 is generally available for all customers. For almost a year we have monitored customer feedback to improve the macOS-11 image stability and now we are ready to set it as the latest.

Possible impact

The macOS-11 image has a different set of software than macOS-10.15. The most significant changes are listed in the table below:

Tool name macOS-10.15 macOS-11 Notes
R lang 4.* - R was not available for Big Sur when we prepared the image for the first time. Please use standard tool request process if the tool needs to be added
Virtualbox and Vagrant 6. and 2. - Virtualbox on macOS 11 requires security preferences changes, which can't be easily done. The PR with virtualbox is not yet merged https://github.com/actions/virtual-environments/pull/4010
Java 8(default)
11
12
13		 8(default)
11		 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.7
3.8
3.9		 EOL python versions were deprecated
PyPy toolcache 2.7
3.6
3.7		 2.7
3.7		 Version 3.6 was deprecated as it won't receive any updates
Go toolcache 1.13
1.14
1.15
1.16
1.17		 1.15
1.16
1.17		 EOL go versions were deprecated
Xamarin.Mono 6.4 - 6.12 6.12 Old versions and versions incompatible with the pre-installed Xcodes were removed
Xamarin.iOS 13.2 - 14.10 13.20 - 14.20 Old versions and versions incompatible with the pre-installed Xcodes were removed
Xamarin.Mac 6.2 - 7.8 6.20 - 7.14 Old versions and versions incompatible with the pre-installed Xcodes were removed
Xamarin.Android 10.0 - 11.2 11.0 - 11.3 Old versions and versions incompatible with the pre-installed Xcodes were removed
Xcode 12.4 (default)
12.3
12.2
12.1.1
12.1
12.0.1
11.7
11.6
11.5
11.4.1
11.3.1
11.2.1
10.3		 13.0 (beta)
12.5.1 (default)
12.5
12.4
11.7		 Only OS-compatible versions left + the latest 11 version
Android SDK build-tools and platforms 24 - 31 27 - 31 Android Platforms and build tools < 27.0 were removed from image. Consider installation in runtime using sdkmanager

Virtual environments affected

Mitigation ways

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

spoelstraethan commented 2 years ago

This should probably be given higher priority or a sooner release date, with iOS 15 becoming widely available to end users on September 20.

In our experience the iOS 15 betas are already requiring the new digital signatures that only seem to be available in Xcode 12.5.x, so any Apple Enterprise program users signing applications with the macos-10.15 image are going to see their apps not launching on iOS 15 if they are installing them via AppCenter.ms or anywhere but TestFlight/App Store.

It appears that Xcode 12.5.x is only available on the macos-11 image and Apple doesn't support it on Catalina aka 10.15 so either you will have a LOT of customers using the default macos-latest image reaching out for support or spending hours (or days) trying to figure out the issue, or you could save them a lot of hassle and update the tag for everybody.

zi6xuan commented 2 years ago

When I compiled the ios version of the flutter project on actions, the script script of the ios project got stuck. Stuck at the last script running. I was stuck for six hours and was eventually cancelled because time ran out.

project: flutter
platform: iOS
tool: fastlane
miketimofeev commented 2 years ago

@zi6xuan feel free to create a new issue and we will try to help you

ettore commented 2 years ago

Meanwhile, this forum post highlights the iOS re-signing details on macOS 10.15 / Xcode 12 to solve the new signature issues on iOS 15 devices: https://developer.apple.com/forums/thread/682775

jimhester commented 2 years ago

FWIW the first R-4.1.1.pkg link for Intel based Macs at https://cloud.r-project.org/bin/macosx/ does support Big Sur (I have been using it on Big Sur myself for months now), however the explanatory text does not seem to have been updated to reflect this.

miketimofeev commented 2 years ago

@jimhester feel free to open Add request in this repo and we will add R to the Big Sur image.

bionanek commented 2 years ago

Just out of curiosity - why does this update take so long after new iOS and MacOS has been already officially released by Apple? I mean, If it's gonna be done by November 3rd it's gonna be +/- 3 months without proper GitHub support for this kind of environments.

palumbo67 commented 2 years ago

Getting the following error when running tns test android on macOS-latest (11.6)

Execution failed for task ':app:stripDebugDebugSymbols'.
No toolchains found in the NDK toolchains folder for ABI with prefix: arm-linux-androideabi

I even get this error when running it against 10.15. Did something change?

miketimofeev commented 2 years ago

@palumbo67 could be related to this https://github.com/actions/virtual-environments/issues/3894

palumbo67 commented 2 years ago

@miketimofeev so I can technically run my unit tests in ubuntu-latest instead of macOS-latest

FarahaDadvarDeveloper commented 2 years ago

Hi All, Any update on when the macOS host agent will support XCode 13? Kind regards

al-cheb commented 2 years ago

Hi All, Any update on when the macOS host agent will support XCode 13? Kind regards

It is already available. https://github.com/actions/virtual-environments/blob/main/images/macos/macos-11-Readme.md

Xcode

Version | Build | Path -- | -- | -- 13.0 (beta) | 13A5212g | /Applications/Xcode_13.0_beta.app 13.0 | 13A233 | /Applications/Xcode_13.0.app
sami1971 commented 2 years ago

When will Xamarin IOS builds support XCode 13? There doesn't seem to be way to make Visual Studio to use 13 instead of Xcode_12.5.1.

FarahaDadvarDeveloper commented 2 years ago

When will Xamarin IOS builds support XCode 13? There doesn't seem to be way to make Visual Studio to use 13 instead of Xcode_12.5.1.

Try this -> https://github.com/xamarin/xamarin-macios/issues/12778

sami1971 commented 2 years ago

xamarin/xamarin-macios#12778

Yes, the updates were published today. Wondering when they will be available on the Azure pipeline. Currently the builds use 12.5.1 as Xamarin.iOS 14.20 is the latest available. Will we be getting 15.0.0.6 anytime soon on the image?

FarahaDadvarDeveloper commented 2 years ago

xamarin/xamarin-macios#12778

Yes, the updates were published today. Wondering when they will be available on the Azure pipeline. Currently the builds use 12.5.1 as Xamarin.iOS 14.20 is the latest available. Will we be getting 15.0.0.6 anytime soon on the image?

Same here, wondering when it's available on the Azure Pipeline

hbeni commented 2 years ago

Hi, I get the following error (https://github.com/hbeni/fgcom-mumble/actions/runs/1293281303): The log tells me, that on macos-latest openssl is not found. Yesterday it run just fine. Today even switching back to macOS-10.15 does drop the same error.

2021-10-01T01:03:56.8559230Z make CC=g++-11 outname=fgcom-mumble-macOS.bundle CFLAGS="-I/usr/local/opt/openssl/include/ -L/usr/local/opt/openssl/lib/" plugin
2021-10-01T01:03:56.9026430Z g++-11 -shared -fPIC -o fgcom-mumble-macOS.bundle lib/radio_model.o lib/audio.o lib/io_plugin.o lib/io_UDPServer.o lib/io_UDPClient.o lib/garbage_collector.o fgcom-mumble.cpp -lssl -lcrypto -DSSLFLAGS -I/usr/local/opt/openssl/include/ -L/usr/local/opt/openssl/lib/ -Wall -O3 -I. -I./lib  -pthread
2021-10-01T01:03:57.2057260Z In file included from ./lib/updater.cpp:55,
2021-10-01T01:03:57.2060090Z                  from fgcom-mumble.cpp:1148:
2021-10-01T01:03:57.2061970Z ./lib/http/httplib.h:210:10: fatal error: openssl/err.h: No such file or directory
miketimofeev commented 2 years ago

Hi @hbeni, you faced the same issue probably https://github.com/actions/virtual-environments/issues/4195

al-cheb commented 2 years ago

Hey, @hbeni Could you please use /usr/local/opt/openssl -> /usr/local/opt/openssl@1.1 path?

hbeni commented 2 years ago

@al-cheb @miketimofeev Thank you, works!

AraHaan commented 2 years ago

Too bad we cant specify that we want the latest MacOS 12 Beta if we are writing code that depends on explicitly using that to build + run tests.

mpbw2 commented 2 years ago

Is there any way to force this rollout? (I'm assuming we don't have it yet since our actions pages still say macOS-latest workflows will use macOS-11 soon) I'm currently unable to build for iOS 15 - Getting 'UITabBar' does not contain a definition for 'ScrollEdgeAppearance'

miketimofeev commented 2 years ago

@mportune-bw you don't need this rollout to build for iOS15. macos-11 runners are already available so the change only affects the macos-latest tag

mpbw2 commented 2 years ago

Thanks @miketimofeev , looks like #4200 is my actual issue.

kofkgoing commented 2 years ago

Today suddenly I've got this error what's wrong??

2021-10-06T13:50:24.7549170Z ❌ ld: could not reparse object file in bitcode bundle: 'Invalid bitcode version (Producer: '1205.0.22.11.0_0' Reader: '1200.0.32.29_0')', using libLTO version 'LLVM version 12.0.0, (clang-1200.0.32.29)' for architecture arm64 2021-10-06T13:50:24.7550020Z 2021-10-06T13:50:24.7550240Z 2021-10-06T13:50:24.7550460Z 2021-10-06T13:50:24.7551550Z ❌ clang: error: linker command failed with exit code 1 (use -v to see invocation)

2021-10-06T13:50:24.7571540Z [13:50:11]: Maybe the error shown is caused by using the wrong version of Xcode 2021-10-06T13:50:24.7572670Z [13:50:11]: Found multiple versions of Xcode in '/Applications/' 2021-10-06T13:50:24.7573780Z [13:50:11]: Make sure you selected the right version for your project 2021-10-06T13:50:24.7575210Z [13:50:11]: This build process was executed using '/Applications/Xcode_12.4.app' 2021-10-06T13:50:24.7576400Z [13:50:11]: If you want to update your Xcode path, either 2021-10-06T13:50:24.7576900Z [13:50:11]: 2021-10-06T13:50:24.7577750Z [13:50:11]: - Specify the Xcode version in your Fastfile 2021-10-06T13:50:24.7578750Z [13:50:11]: ▸ xcversion(version: "8.1") # Selects Xcode 8.1.0 2021-10-06T13:50:24.7579250Z [13:50:11]: 2021-10-06T13:50:24.7580190Z [13:50:11]: - Specify an absolute path to your Xcode installation in your Fastfile 2021-10-06T13:50:24.7581300Z [13:50:11]: ▸ xcode_select "/Applications/Xcode8.app" 2021-10-06T13:50:24.7581820Z [13:50:11]: 2021-10-06T13:50:24.7582600Z [13:50:11]: - Manually update the path using 2021-10-06T13:50:24.7583610Z [13:50:11]: ▸ sudo xcode-select -s /Applications/Xcode.app

benr75 commented 2 years ago

Xcode 12.1 is required for our builds. On App Center this will cause the use a macOS 10 image, successfully complete the build, but the signed IPA is not installable on iOS 15 due to signing changes solved in macOS 11 + Xcode 12.1.

I believe App Center is using this image for macOS 11 under the hood. My work around was going to be to set our Xcode version to 12.5 to get a macOS 11 image, then xcode-select to 12.1 - HOWEVER as noted here 12.1 is not on the box.

I've gone back and forth with MS support but have received no help. I cannot quickly upgrade our apps to be compatible with 12.5. Any help or guidance appreciated.

kofkgoing commented 2 years ago

Oh I solved my problem lastnight with runs-on: macos-11 instead of runs-on: macos-latest

thank you

akinncar commented 2 years ago

Why Xcode 12.5 was removed from macos-11? image

andreyluiz commented 2 years ago

@akinncar Refer to https://github.com/actions/virtual-environments/issues/4183.

Mizux commented 2 years ago

Since #4010 is closed unmerged. I would be happy to know which alternative to use to test FreeBSD ?

context: Currently for google/cpu_features and google/or-tools we are using Vagrant+VirtualBox (in a macOS-10.15 virtual-environnment) since it the only way to test FreeBSD using github runners.... so removing VirtualBox/Vagrant is just killing our workflow and our ability to support the FreeBSD ecosystem..

miketimofeev commented 2 years ago

@Mizux you can continue using macOS-10.15 for your needs, it is still supported.

NightOwl888 commented 2 years ago

I don't see netcoreapp3.1 in the list above, but we are getting the following error when set to maOS-latest that goes away when we use macOS-10.15:

The active test run was aborted. Reason: Test host process crashed
Data collector 'Blame' message: Data collector caught an exception of type 'System.PlatformNotSupportedException': 'Unsupported target framework .NETCoreApp,Version=v3.1 on OS Darwin 19.6.0 Darwin Kernel Version 19.6.0: Tue Aug 24 20:28:00 PDT 2021; root:xnu-6153.141.40~1/RELEASE_X86_64'. More details: Blame: Creating hang dump failed with error...
Data collector 'Blame' message: Data collector caught an exception of type 'System.IO.FileNotFoundException': 'Collect dump was enabled but no dump file was generated.'. More details: Blame: Collecting hang dump failed with error...
Test Run Aborted.

It makes sense that .NET Core 3.1 wouldn't be fully supported on macOS-11, but it would be useful if that were documented here.

Mizux commented 2 years ago

@NightOwl888 should be supported according to https://github.com/actions/virtual-environments/blame/main/images/macos/macos-11-Readme.md#L14 EDIT: my bad while the SDK is installed doesn't means the SDK support the platform...

miketimofeev commented 2 years ago

@NightOwl888 we are not aware of such incompatibilities and haven't received any complaints until now

NightOwl888 commented 2 years ago

Lucene.Net.Tests._J-S.zip

Here is all of the info that is recorded as artifacts. As you can see, the tests complete until the end, all passing, and the crash happens afterward. Then it attempts to write a dump file, but fails to write anything.

Environment

Note the build was done on the entire solution using .NET SDK 6.0.100-rc.2.21505.57. But the above scenario just uses the binaries from the testbinaries artifact.

NOTE: Despite the name of the log, we are using dotnet test rather than dotnet vstest as the command.

If you are unable to reproduce with the above info, we are open source and have our project set up so anyone can run the build with Azure DevOps by pointing to the azure-pipelines.yml file in the repo root (variables are documented at the top of the file, but none are required) (docs). The failure happened at this commit: https://github.com/apache/lucenenet/commit/2023eda9091dc1e4428644bf48b0d0cb23946397. But it is very intermittent, and I am sure that targeting macOS-11 directly will make it happen more frequently.

miketimofeev commented 2 years ago

@NightOwl888 actually Darwin 19.6.0 is macos-10.15. And macos-latest either points for your organization to macos-11 or not — there can't be any borderline situation when some of your builds are run on macos-10.15 and the others are on macos-11 when you set macos-latest spec. Could you provide a link to the failed run?

NightOwl888 commented 2 years ago

@miketimofeev - Thanks for that info.

Unfortunately, the run that failed was during a release. When we re-ran the job, the test artifacts in that case were attempting to create an artifact with the same name, which also failed. So, we ended up deleting the run so we could build the release successfully. We only had one other failure and we ended up using it to troubleshoot how to get around the problem of not being able to re-run the failed job because the artifact already existed.

Here is the failure that had since been re-run (which wiped out the original crash message in the dashboard, but the artifacts are still the originals):

https://dev.azure.com/lucene-net-temp3/Lucene.NET/_build/results?buildId=502&view=results

NOTE: It helps a lot to unzip the files in a local folder, then search for *-error.log and look for log files with more than 0 bytes. In that case it was the Lucene.Net.Tests.Cli project that failed.

And if it helps, here is the pipeline where we deleted the failed run, which also had the build number 4.8.0-beta00015:

https://dev.azure.com/lucene-net/Lucene.NET/_build?definitionId=3&_a=summary

actually Darwin 19.6.0 is macos-10.15.

If that is true, then there must be some issue with Azure DevOps, because as you can see below, we are definitely using macOS-latest in the build on both runs (although you are using a different casing of macos-latest instead of macOS-latest from the official docs, if that makes any difference).

We hadn't seen this error until very recently, but I see that we were at macOS-10.15 prior to the recent change to macOS-latest. At first I thought it was due to the change to the .NET 6 RC2 SDK because we didn't see it on .NET 6 RC1 SDK. But it doesn't seem that sensible to assume .NET 6 is the cause because we aren't installing either of those SDKs on the test agent.

We can continually run both commits that failed until we see it again, but it isn't clear what use that will be since the dump data fails to write to the disk. According to the docs:

--blame-crash (Available since .NET 5.0 preview SDK)

Crash dumps in native code, or when using .NET Core 3.1 or earlier versions, can only be collected on Windows, by using Procdump. A directory that contains procdump.exe and procdump64.exe must be in the PATH or PROCDUMP_PATH environment variable. Download the tools. Implies --blame.

So, it would seem that even including the --blame-crash switch wouldn't help for this scenario.

Being that it doesn't write a dump file, will you be able to glean any more info out of Azure DevOps if we get it to happen again?

AraHaan commented 2 years ago

For the .NET SDK all of them had issues on MacOS when they have an ARM64 build of macos and need to compile for x64 and arm64. Basically that issue was fixed in the .NET 6 installers where the ARM64 build of the SDK will not overwrite the x64 one, and the x64 one won't overwrite the ARM64 one when needing to build programs for both targets.

As such I think it's safe to default .NET to .NET 6 and only ship the 6.0.XXX .NET SDK's with the github actions worker.

I have no issues even with older projects that used older .NET SDKs with the newer SDKs and it works well.

jthegeman commented 2 years ago

What will be the MSBuild version on MacOS 11 hosted builds?

wojsmol commented 2 years ago

@jthegeman MSBuild 16.6.0.15801 (from /Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/15.0/bin/MSBuild.dll) quoting from macos-11-Readme.md. You can now test compatibility by switching to macos-11 label.

jthegeman commented 2 years ago

@wojsmol Thanks. Was hoping this was 16.8 at the least. Having issues with the new Refit building on Mac-Hosts. Had to downgrade to previous version.

miketimofeev commented 2 years ago

@jthegeman we are working on adding a new mono version with MSbuild 16.9

AraHaan commented 2 years ago

Uh why install mono just for msbuild when you can alias dotnet msbuild as msbuild?

That way if someone changes their dotnet version it would also update the msbuild they want to use as well.

pronebird commented 2 years ago

Since macOS 11 it's impossible to symlink iOS 12.4 runtime, since Xcode 10.3 is not shipped with the image anymore. Without it it's impossible to run tests for apps that support iOS 12 - 15 range. The one would need Xcode 13 for that.

Using Xcode-install I can easily add iOS 12 sim but it takes 10 minutes to install.

xcversion simulators --install='iOS 12.4 Simulator'

Please provide some sort of solution to avoid doing that because it takes very long time to get anything tested.

Rus1an31 commented 2 years ago

@miketimofeev Today is November, 2. We're still see warnings "##[warning]macOS-latest pipelines will use macOS-11 soon" in our builds. Can you tell please when migration will be completed? It's blocking us to use iOS 15.

miketimofeev commented 2 years ago

@Rus1an31 sorry for the inconvenience, the migration is delayed till December. You can explicitly point your builds to the macos-11 image label until that.

joshepkt commented 2 years ago

When doing a nuget restore on a xamarin solutions with windows, ios, and android I am getting ##[error]The nuget command failed with exit code(1) and error(/Users/runner/work/1/s/YYY/YYY.UWP/YYYY.UWP.csproj : error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project. It works if the vmImage version is 11.6, but not 11.6.1

MaksimZhukov commented 2 years ago

Hello @joshepkt! We have updated Mono version from 6.12.0.125 to 6.12.0.140. The default behavior of the nuget restore command has been changed. Previously, this command skipped restoring for project if the project file is invalid. For now, it throws the error.

Could you please confirm if restoring for the YYYY.UWP.csproj project was skipped in your successful builds?

Also, could you please try using dotnet restore or msbuild -t:restore command as a possible workaround?

krishpranav commented 2 years ago

is there any way to sign development team to build a swift ios app in GitHub workflows????

joshepkt commented 2 years ago

@MaksimZhukov, Yes in the ones that worked, it looks like it errored out and skipped the UWP project.

From a working one: /Users/runner/work/1/s/YYYY/YYYY.UWP/YYYY.UWP.csproj : error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project. /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/NuGetScratch/rque8wsk.68l.nugetrestore.targets(315,5): warning : Skipping restore for project '/Users/runner/work/1/s/YYYY/YYYY.UWP/YYYY.UWP.csproj'. The project file may be invalid or missing targets required for restore. [/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/NuGetScratch/9ax69yfn.nz4.nugetinputs.targets]

I was able to work around by explicitly running the restore command for the csproj file and its referenced project(s). I will work on switching it to msbuild -t:restore and see if that works.