I'm using Fastlane for my CI builds on Github Actions.
CI runs Fastlane's build_app function. The build_app internally uses xcodebuild archive to archive the project and then uses xcodebuild -exportArchive to extract IPA.
The problem is xcodebuild archive always ignores caches and builds all the modules from the source (even if DerivedData from previous builds are available). Is there a way to force either fastlane or xcodebuild archive to use caches from DerivedData. Or maybe there is some other way to achieve this.
Thanks
Related
On my hand is an Xcode project, comprising of a number of static libraries, and an iOS application that consumes them (we do not intend to release the libraries). Part of it is a crash reporting implementation based on Google Breakpad.
An issue that we've found is that we aren't getting line number information in crash reports for the libraries, from our releases. These are generated using xcodebuild archive -project ${PROJECT_PATH} -scheme ${SCHEME_NAME} -archivePath ${OUTPUT_PATH} -UseModernBuildSystem=NO -IDEBuildingContinueBuildingAfterErrors=YES. EDIT: using Xcode 12.
If, instead of archive, I run the xcodebuild build action with the same options (exc. archivePath of course) - or build the project in the IDE -, then I get complete symbol information and everything works (at least testing on iOS Simulator). This seems to be the only difference - of course then I'd still need to produce an .ipa somehow.
The build options are shared between all libraries and application, and include the following:
COPY_PHASE_STRIP = YES
DEPLOY_POSTPROCESSING = YES
SEPARATE_STRIP = YES # tried to change each of these to NO in various permutations; no difference.
STRIP_STYLE = non-global
What is the difference between the steps that the build and the archive actions perform, with regards to stripping?
How can I create the .ipa from the artifact of the xcodebuild build, or otherwise coerce xcodebuild archive to omit / delay stripping, so that I may perform that manually once I've dumped the symbols?
It might be worth mentioning that I've tried combinations of the xcodebuild actions as well, i.e. clean build archive in one or separate steps - makes no difference.
(FWIW, I realise that the PackageApplication command of xcrun was deprecated as of Xcode 8.3.)
Here is how we are setup while facing the issue.
We have a project which has both UI and Unit tests.
Uses fastlane.
Has CI/CD implementation using Jenkins which runs on an aws ec2 instance.
Quite recently we moved to Xcode12 (I know!!! However, better late than never)
Problem statement:
After moving to xcode12, the jenkins pipeline is unable to generate the Coverage.profdata file which in turn will be used by Slather to derive code coverage metrics. Yes, did not happen when running xcode11.
We are using the xcodebuild command after pointing it to the appropriate command line tool version (in this case it is 12.4).
First we build the app using (after getting the simulator ID)
xcodebuild build-for-testing -workspace Example.xcworkspace -scheme ExampleUITests -derivedDataPath ./derivedData -destination 'platform=iOS Simulator,id=<simulator_id>'
Then we run the test using
xcodebuild test-without-building -workspace Example.xcworkspace -scheme ExampleUITests -enableCodeCoverage YES -destination 'platform=iOS Simulator,id=<simulator_id>' -derivedDataPath ./derivedData
All the UI tests run successfully but end up with the following statements when the test suite completes.
warning: <Path_to_derived_data>/Build/ProfileData/<Some_UUID>/<Filename>.profraw: Invalid instrumentation profile data (file header is corrupt)
error: No profiles could be merged.
P.S: This is not happening on my local machine. Only on the mac in the Jenkins ec2 instance.
We faced a similar issue. We were also using fastlane.
And the fix which worked for us was to ensure we delete any artifacts from the previous build. The situation you've described is quite similar to situation we faced. The first run for unit tests generates a few coverage artifacts, after which executing UI tests also generates coverage artifacts and then xcov/slather is unable to parse these artifacts.
Therefore, can you check if deleting the Logs/Test folder in derived data helps? If it doesn't try clearing derived data entirely and then check if that helps resolve the issue on CI.
See related threads on xcov
I'm trying to automate iOS building through CMake, up to and including authoring .ipas. I have my provisioning profile and certificates set up, build is successful, but when I execute cmake --build I can't get .xcarchives to generate, and my POST_BUILD command (using xcodebuild) to author the .ipa is dependent on that.
I've tried setting some archive options though CMake (setting cmake_archive_output_directory), but there's a flag or option to set that can produce xcarchives during build, I don't know it. Does anyone have experience with this?
Despite many attempts, a post-build command to xcodebuild archive never worked -- I'm still not sure why, either. What I ended up doing to work around this was have CMake generate a script.
So my create executable custom function does this:
It creates a script file if it doesn't already exist, then for each executable target, appends an xcodebuild command if it's not a duplicate:
xcodebuild -workspace ${pathToTargetWorkspace} -scheme ${targetScheme} -configuration ${config} -archivePath ${pathToGeneratedArchive}.xcarchive archive
Then after building is finished, you just run the script with the aggregation of archive commands and it archives all the targets.
I am using xcodebuild to generate an archive from a workspace. I use the following command:
xcodebuild -workspace MyProject.xcworkspace -scheme "MyProject"
-destination generic/platform=iOS archive
-archivePath "../PathToArchive/MyProject.xcarchive
(I've spaced it out over multiple lines for readability)
This command generates a MyProject.xcarchive. However it generates a generic "Xcode Archive" rather than an "iOS App Archive." This cannot be submitted to the App Store.
If I archive the exact same workspace and scheme using Xcode.app version 7.0.1 (7A1001) instead of xcodebuild then I get an "iOS App Archive" which can be submitted to the App Store.
Inspecting the contents of these two xcarchives shows the main difference is the bundled Info.plist file. The one generated by Xcode.app contains an additional ApplicationProperties dict with versioning and signing details. The one generated by xcodebuild lacks these details in its Info.plist.
Copying the Xcode.app generated Info.plist into the xcarchive generated by xcodebuild "fixes" the archive, and it can be submitted to the App Store. This is not a solution however, as it means I cannot build on the command line.
Note that doing xcodebuild -version prints:
Xcode 7.0.1
Build version 7A1001
Edit: sometimes xcodebuild appears to generate a correct iOS App Archive instead of a Generic Archive. I'm not exactly sure why this happens. It's not consistent.
Are you using Cocoapods? If so try using the pre release version gem install cocoapods --pre . I had the issue because of a copy pods phase being somewhere it should not have been, please go through https://github.com/CocoaPods/CocoaPods/issues/4021 you should find a solution that fits you.
After a lot of frustration I have discovered the cause of xcodebuild producing incorrect xcarchive packages.
I had to disable the "Parallelize Build" option for the scheme I was building.
After un-ticking this option, the builds take a lot longer, but xcodebuild is consistently producing an "iOS App Archive" rather than a "Generic Archive." With "Parallelize Build" enabled xcodebuild would generate a "Generic Archive" 90% of the time, occasionally generating a correct archive.
Because I wanted my build times within Xcode to remain unaffected, I left the "Parallelize Build" option enabled for my schemes. I duplicated the schemes to be built with xcodebuild and un-ticked the option only for the deployment schemes.
I have an Xcode project that contains several sub-projects (framework projects that compile as lib files) as part of the main project. The project compiles/builds properly in Xcode (builds the sub-projects correctly from the bottom of the hyarchial tree up to the main app project).
I am now trying to set up the project for Continuous Integration, and when I attempt to build from the command line using xcodebuild... the build fails due to not finding the .a files that should have been built before the main project.
I can build each of the lib files from the cmd line independently, but the entire consolidated project fails. Even though I have the dependancies correctly managed in the target scheme and if I specify the target or scheme when I use xcodebuild, it still will not build the sub-projects.
Is there a way to make xcodebuild build the sub-projects and then the main project as it does in the Xcode IDE? If not, would this work if I converted the entire project into a workspace?
Any help or suggestions would be greatly appreciated. I am running Xcode 5.1.1 on Mavericks.
The solution was a simple one... using the "-scheme" flag instead of "-target" allowed the project to build correctly (all sub-projects/frameworks and then target App)
FAILED:
xcodebuild -project MyProject.xcodeproj -target MyProject -sdk "iphoneos" -configuration “Build” archive OBJROOT=../../build_iOS/Obj.root SYMROOT=../../build_iOS/Sym.root
BUILT AS EXPECTED:
xcodebuild -project MyProject.xcodeproj -scheme MyProject -sdk "iphoneos" -configuration “Build” archive OBJROOT=../../build_iOS/Obj.root SYMROOT=../../build_iOS/Sym.root
There was no need to convert the project to a workspace.
You need to use a workspace to build multiple projects. Also, since you are moving to a CI server, be sure to share your schemes.