I've recently being getting an intermittent issue on my builds. My post-clone script calls yarn install to set up dependencies for the app. Occasionally it will fail at this step fetching packages, on what I'm assuming is the package stored in a private gitlab repository for the company. The repository is accessible over the internet for ssh, and uses ssh keys for authentication. I install the private key at the start of the script, it's stored as an environment variable in the workflow configuration. Here's what the error looks like, note that the cert altnames are different every time: [2/4] Fetching packages... error Error [ERR_TLS_CERT_ALTNAME_INVALID]: Hostname/IP does not match certificate's altnames: Host: <private-repo.com>. is not in the cert's altnames: DNS:*.outsystemsenterprise.com, DNS:outsystemsenterprise.com at new NodeError (node:internal/errors:387:5) at Object.checkServerIdentity (node:tls:354:12) at TLSSocket.onConnectSecure (node:_tls_wrap:1549:27) at TLSSocket.emit (node:events:513:28) at TLSSocket._finishInit (node:_tls_wrap:953:8) at TLSWrap.ssl.onhandshakedone (node:_tls_wrap:734:12)

Xcode Cloud build on Xcode 14.3.1 and MacOS Ventura 13.5.2 worked on 1/26/2024 and is failing this week (1/29/2024 ->) for multiple React Native apps. This happens in branches that have not changed since the last successful build. Local builds and 'pod install's continue to work. Any help is appreciated. ci_post_clone.sh ################## Set Up Environment ################################## export HOMEBREW_NO_INSTALL_CLEANUP=TRUE brew install cocoapods # have to add node yourself brew install node@16 # link it to the path brew link node@16 # local npm/jfrog auth method ... # move to the project directory cd .. npm ci # Install dependencies you manage with CocoaPods. cd ios pod install Run ci_post_clone.sh script ... Installing boost (1.76.0) Installing fmt (6.2.1) Installing glog (0.3.5) Installing hermes-engine (0.71.11) [!] Error installing hermes-engine ――― MARKDOWN TEMPLATE ――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― Command /usr/local/Cellar/cocoapods/1.15.0/libexec/bin/pod install Report What did you do? What did you expect to happen? What happened instead? Stack CocoaPods : 1.15.0 Ruby : ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-darwin22] RubyGems : 3.5.4 Host : macOS 13.5.2 (22G91) Xcode : 14.3.1 (14E300c) Git : git version 2.39.2 (Apple Git-143) Ruby lib dir : /usr/local/Cellar/ruby/3.3.0/lib Repositories : trunk - CDN - https://cdn.cocoapods.org/ Plugins cocoapods-deintegrate : 1.0.5 cocoapods-plugins : 1.0.0 cocoapods-search : 1.0.1 cocoapods-trunk : 1.6.0 cocoapods-try : 1.2.0 Podfile require File.join(File.dirname(`node --print "require.resolve('expo/package.json')"`), "scripts/autolinking") require_relative '../node_modules/react-native/scripts/react_native_pods' require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules' platform :ios, '13.0' prepare_react_native_project! # If you are using a `react-native-flipper` your iOS build will fail when `NO_FLIPPER=1` is set. # because `react-native-flipper` depends on (FlipperKit,...) that will be excluded # # To fix this you can also exclude `react-native-flipper` using a `react-native.config.js` # ```js # module.exports = { # dependencies: { # ...(process.env.NO_FLIPPER ? { 'react-native-flipper': { platforms: { ios: null } } } : {}), # ``` flipper_config = ENV['NO_FLIPPER'] == "1" ? FlipperConfiguration.disabled : FlipperConfiguration.enabled linkage = ENV['USE_FRAMEWORKS'] if linkage != nil Pod::UI.puts "Configuring Pod with #{linkage}ally linked Frameworks".green use_frameworks! :linkage => linkage.to_sym end target 'UI Kit App' do # Required by Expo modules use_expo_modules! post_integrate do |installer| begin expo_patch_react_imports!(installer) rescue => e Pod::UI.warn e end end config = use_native_modules! # Flags change depending on the env values. flags = get_default_flags() use_react_native!( :path => config[:reactNativePath], # Hermes is now enabled by default. Disable by setting this flag to false. # Upcoming versions of React Native may rely on get_default_flags(), but # we make it explicit here to aid in the React Native upgrade process. #:hermes_enabled => flags[:hermes_enabled], :hermes_enabled => true, :fabric_enabled => flags[:fabric_enabled], # Enables Flipper. # # Note that if you have use_frameworks! enabled, Flipper will not work and # you should disable the next line. :flipper_configuration => flipper_config, # An absolute path to your application root. :app_path => "#{Pod::Config.instance.installation_root}/.." ) post_install do |installer| react_native_post_install( installer, # Set `mac_catalyst_enabled` to `true` in order to apply patches # necessary for Mac Catalyst builds :mac_catalyst_enabled => false ) __apply_Xcode_12_5_M1_post_install_workaround(installer) end end Error Errno::EEXIST - File exists @ syserr_fail2_in - /Users/local/Library/Caches/CocoaPods/Pods/External/hermes-engine/fb17fa7201e9c4777a414e0d9d28892e-34c86/destroot/Library/Frameworks/universal/hermes.xcframework/ios-arm64_x86_64-maccatalyst/hermes.framework/Resources /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2254:in `symlink' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2254:in `copy' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:1048:in `block in copy_entry' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2385:in `wrap_traverse' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2388:in `block in wrap_traverse' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2387:in `each' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2387:in `wrap_traverse' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:1045:in `copy_entry' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:990:in `block in cp_r' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2469:in `block in fu_each_src_dest' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2478:in `block in fu_each_src_dest0' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2476:in `each' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2476:in `fu_each_src_dest0' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:2467:in `fu_each_src_dest' /usr/local/Cellar/ruby/3.3.0/lib/ruby/3.3.0/fileutils.rb:989:in `cp_r' /usr/local/Cellar/cocoapods/1.15.0/libexec/gems/cocoapods-1.15.0/lib/cocoapods/downloader/cache.rb:343:in `block (2 levels) in copy_files' ... /usr/local/Cellar/cocoapods/1.15.0/libexec/bin/pod:25:in `load' /usr/local/Cellar/cocoapods/1.15.0/libexec/bin/pod:25:in `<main>' ――― TEMPLATE END ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― [!] Oh no, an error occurred. Search for existing GitHub issues similar to yours: https://github.com/CocoaPods/CocoaPods/search?q=File+exists+%40+syserr_fail2_in+-+%2FUsers%2Flocal%2FLibrary%2FCaches%2FCocoaPods%2FPods%2FExternal%2Fhermes-engine%2Ffb17fa7201e9c4777a414e0d9d28892e-34c86%2Fdestroot%2FLibrary%2FFrameworks%2Funiversal%2Fhermes.xcframework%2Fios-arm64_x86_64-maccatalyst%2Fhermes.framework%2FResources&type=Issues If none exists, create a ticket, with the template displayed above, on: https://github.com/CocoaPods/CocoaPods/issues/new Be sure to first read the contributing guide for details on how to properly submit a ticket: https://github.com/CocoaPods/CocoaPods/blob/master/CONTRIBUTING.md Don't forget to anonymize any private data! Looking for related issues on cocoapods/cocoapods... Found no similar issues. To create a new issue, please visit: https://github.com/cocoapods/cocoapods/issues/new

I think it would be beneficial for those of us distributing outside the Mac App Store to be able to run a custom script after the notarization post-action on Xcode Cloud, to upload the notarized binary to something like S3. Will this workflow be considered or implemented in the future? Right now, it's only possible to run a custom script post-build rather than post-notarization.

I am doing brew install awscli with my ci_post_clone.sh. When doing so, I get the following error and awscli can no longer be installed. I remember that this error did not occur at the time of macOS Ventura 13.6.3, xcode 14.3.1 and only occurred after upgrading to macOS Sonoma 14, xcode 15.0.1, but I am now getting the same error after reverting back to macOS Ventura 13.6.3, xcode 14.3.1. Error: python@3.11: the bottle needs the Apple Command Line Tools to be installed. You can install them, if desired, with: xcode-select --install xcode-select --install If you're feeling brave, you can try to install from source with: brew install --build-from brew install --build-from-source python@3.11 I know that awscli depends on python 3.11, but I don't think it's an awscli problem because I was using awscli before the error appeared and was able to use it without any problems. I am wondering why the error suddenly appeared and whether the response to put brew install --build-from-source python@3.11 is correct. Thank you in advance for your response.

Since this morning, visionOS builds in XCode Cloud are failing. Did change anything in my configuration, the error on XCode cloud looks like visionOS is not installed: { platform:visionOS, id:dvtdevice-DVTiOSDevicePlaceholder-xros:placeholder, name:Any visionOS Device, error:visionOS is not installed. To use with Xcode, first download and install the platform } I attached a screenshot from the logs. Anyone know what is happening here and how to fix? Thanks, Patrick

Five days ago everything was working as intended. Nothing has been changed on Workflows. All of a sudden, new builds are failing. The issue is with these two tasks during the Archiving: Export archive for ad-hoc distribution Export archive for app-store distribution I downloaded the Artifacts and checked the logs. If we look at the IDEDistribution.verbose.log then we see the following errors: "Error Domain=IDEProfileLocatorErrorDomain Code=1 \"No profiles for 'uz.uzum.avto' were found\" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedDescription=No profiles for 'uz.uzum.avto' were found, NSLocalizedRecoverySuggestion=Xcode couldn't find any iOS App Store provisioning profiles matching 'uz.uzum.avto'.}", "Error Domain=DeveloperAPIServiceErrorDomain Code=5 \"There is a problem with the request entity\" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedDescription=There is a problem with the request entity, NSLocalizedRecoverySuggestion=You already have a current Distribution Managed certificate or a pending certificate request.}", "Error Domain=IDECodesignResolverErrorDomain Code=1 \"No signing certificate \"iOS Distribution\" found\" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedRecoverySuggestion=No \"iOS Distribution\" signing certificate matching team ID \"x\" with a private key was found., IDEProvisioningError_UserInfoKey_IDEProvisioningErrorSpecifier=iOS Distribution, NSLocalizedDescription=No signing certificate \"iOS Distribution\" found, IDEProvisioningError_UserInfoKey_IDEProvisioningErrorPlatform=com.apple.platform.iphoneos, IDEProvisioningError_UserInfoKey_IDEProvisioningErrorAction=5, IDEProvisioningError_UserInfoKey_IDEProvisioningErrorTeam=<IDEProvisioningBasicTeam: 0x600001866280; teamID='x', teamName='(null)'>}" )} Issues seems to be related to certificates and etc. However, I checked the member center, and everything is fine with the certificates and profiles. Moreover, I can build, archive and distribute from my local machine with no issues at all. One particular thing that got my interest is the following: I opened the IDEDistribution.critical.log file, and saw the following issue: It seems Xcode Cloud is having a hard time to connect to App Store Connect. Please, help me to resolve the issue. I tried to change the Environment, to add new provisioning profile, but nothing works. FYI: I tried different environments to build, but the latest was: Xcode 15.0.1 macOS: Ventura 13.6.3 platform: iOS Deployment Preparation: Testflight (Internal Testing Only)

After months of the same script working properly, all of sudden, as of last night, our ci_post_clone.sh started failing with following error: The ci_post_clone.sh is not executable and was run using zsh (default shell on macOS). To make sure your script runs correctly, make the file executable using `chmod +x` and add an appropriate shebang line. Here's what I've done: Re-applied: git update-index --chmod=+x ./ci_scripts/ci_post_clone.sh; still failed to execute returning same error I was using older flutter version so changed the flutter branch to stable - still same error. App code builds fine in local Xcode! APPRECIATE ANY HELP! Here is the script. #!/bin/sh # ci_post_clone.sh # Runner # # set -e echo "Running post clone script" # The default execution directory of this script is the ci_scripts directory. cd $CI_WORKSPACE # change working directory to the root of your cloned repo. # Install Flutter using git. git clone https://github.com/flutter/flutter.git --depth 1 -b stable $HOME/flutter export PATH="$PATH:$HOME/flutter/bin" # Install Flutter artifacts for iOS (--ios), or macOS (--macos) platforms. echo "Doing precache" flutter precache --ios echo "Installing cocoa pods" # Install CocoaPods using Homebrew. HOMEBREW_NO_AUTO_UPDATE=1 # disable homebrew's automatic updates. brew install cocoapods echo "calling pub get" # Install Flutter dependencies. flutter pub get echo "executing pod install" # Install CocoaPods dependencies. cd ios && pod install # run `pod install` in the `ios` directory. exit 0

Hello everyone! I've noticed that Xcode 15.2 is still not selectable as a build environment on Xcode Cloud, even though the official version of 15.2 has been out for several days. Is this part of the plan? Or is it a system bug? 🤔 I need 15.2 as the release environment, including support for building visionOS apps. I have already submitted FB13531029.

Hi there, In my custom script in ci-scripts, I had to call my git repository rest api to fetch registries (but also had to create tags, releases and more...) I added an ad-hoc secret environment variable to my workflow with a fresh access token as explained in this WWDC Video. But I wonder : Is there a way to get the git repository Access Token we provide to Xcode Cloud when we associate it to our git repository following the Source code management setup page as an Environment Variable of the project Workflows ? If I get it right, before I had the had-oc access token, I was able to clone the other git repositories of my project... So IMHO, the access token provided during the setup should be available somewhere (at least for the git commands).

Just a quick tip from what I discovered in the build times of our app in Xcode Cloud. Beware of selecting another simulator device instead of one of the recommended iPhones. Prepare Simulator Custom device: ~3m Recommended device: ~3s I assume Xcode Cloud comes preconfigured with the recommended iPhone. Any other device will take ~3m to setup in the testing step. (At least this is my assumption, please correct me if you have different findings.) You don't have to use all recommended iPhone. It will work if you just select one of them.

Xcode Cloud Builds seem flaky to me. Sometimes the test step fails (not necessarily the tests itself, but the step as a whole). Xcode Cloud seems to re-attempt this step. In my most extreme example, took 3 attempts to run them. For a build which usually takes 22m, it took 1h9m, but billed just 29m. Does anyone else experience this? PR-builds with a duration of >1h are not really acceptable. Here is the protocol. Testing usually takes <3 minutes.

Hi, we're trying to reduce the Xcode Cloud usage in our project, and in the logs of the "Test" action I can see that there's a "Save artifacts" step that takes quite a while (more than 10 minutes), and it looks like a "fixed cost" that's impossible to reduce by improving the build and the tests themselves. In the "Artifacts" section of the Xcode Cloud build I can see that there a "Test Products" zip that's almost 5GB, which seems to be the cause of this slowness (I could verify that in other projects the same zip is smaller, and the "Save artifacts" step is much faster, as a result), but this seems a waste: we never need to download that "Test Products" zip, and its upload takes literally 10 fixed minutes from every single build with a "Test" action. Is it possible to either stop uploading the "Test Products" zip? Or maybe to skip the "Save artifacts" step entirely? Thanks

I have been trying for a couple of days now to get Xcode cloud running. But after some struggle with cocoapods the ci_post_clone.sh is working. But now it fails at the archive section with no real explenation what went worng. I have my profisioning profile connected to the right bundle-id. Run command: 'xcodebuild archive -workspace /Volumes/workspace/repository/wevize/ios/Runner.xcworkspace -scheme Runner -destination generic/platform=iOS -archivePath /Volumes/workspace/build.xcarchive -derivedDataPath /Volumes/workspace/DerivedData -resultBundleVersion 3 -resultBundlePath /Volumes/workspace/resultbundle.xcresult -resultStreamPath /Volumes/workspace/tmp/resultBundleStream34ff2ba9-cd2a-4e3b-befb-3243d688c7f5.json -IDEPostProgressNotifications=YES CODE_SIGN_IDENTITY=- AD_HOC_CODE_SIGNING_ALLOWED=YES CODE_SIGN_STYLE=Automatic DEVELOPMENT_TEAM=KTJT289M8K COMPILER_INDEX_STORE_ENABLE=NO -hideShellScriptEnvironment'

All the steps within our Archive action complete as expected with green checkmarks (including all Prepare Build for App Store Connect steps), but the Archive action itself never completes. It keeps spinning and never passes it off to the post-action to release the build to TestFlight. The system status page says Xcode Cloud had issue for multiple days this week, but they resolved 14 hours ago. I've re-run our build several times today and keep running into this problem. Is this something server-side?