In order to test localisation, I have an Xcode scheme configured to specify simulator locale settings. The scheme appears as follows:
-AppleLocale $(LANG)_$(COUNTRY)
-AppleLanguages ($(LANG))
Passing the above arguments to the simulator has the desired effect if LANG and COUNTRY are defined as build settings in the target.
For convenient automation, I'd like to be able to override the build settings from xcodebuild. However, when I run the following to override the target build settings, the locale of the simulator remains unchanged.
xcodebuild test -workspace MyApp.xcworkspace -scheme 'App UI Tests' -destination 'name=iPad Air' LANG=es COUNTRY=ES
It seems the default build settings from the target are used, regardless of any overrides specified at the terminal.
As an alternative, I could specify the locale code directly in the scheme. Then I could duplicate the scheme for every locale. It seems like a lot of duplication, but perhaps it is more the intended usage of schemes.
Am I missing something? Is this a feature of schemes by design, or could it be an issue with Xcode?
Related
why xcodebuild building the same application differently for scheme and target options?
xcodebuild -target uConnect build
Above commands builds with Release config in build folder inside
project.
xcodebuild -scheme uConnect build
Above builds with Debug config in Xcode’s DrivedData folder.
Wanted to understand what difference -target and -scheme options are making here?
As per my understanding it should always build the application in Release mode since we have selected Release at Project>>Info>>Configuration
use Release for command-line builds
Reference:
Screenshot of Scheme Details for reference
Try editing the scheme. You will see that it specifies the Debug configuration when building. It might look like this:
But, as you've said, when you build the target, you've specified the Release configuration.
A target describes a product that Xcode will build, like your app, the tests, an App Clip or an Extension. When using -target, it will use the configuration specified in the drop down at the bottom of your screenshot.
A scheme is a configuration that describes how a specific target will be built under different circumstances. If you go to the scheme editor, you'll see that you can choose which configuration to build when running, testing, profiling, analyzing, and archiving.
I'm trying to run Facebook's WebDriverAgent, for testing on real devices: https://github.com/facebook/WebDriverAgent.
Our admin isn't a fan of Apple's automatic signing, so we're trying manual. When I put
xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination id='4xxx9' test DEVELOPMENT_TEAM=xxxx PROVISIONING_PROFILE=xxxxx
it says
Testing failed:
WebDriverAgentLib has conflicting provisioning settings. WebDriverAgentLib is automatically signed, but provisioning profile xxxx has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor, or switch to manual signing in the project editor.
I set manual signing on everything (in xcode), and try again:
xcodebuild -project WebDriverAgent.xcodeproj -scheme WebDriverAgentRunner -destination id='4xxx9' test DEVELOPMENT_TEAM=xxxx PROVISIONING_PROFILE=xxxxx
Testing failed:
WebDriverAgentLib does not support provisioning profiles. WebDriverAgentLib does not support provisioning profiles, but provisioning profile xxxx has been manually specified. Set the provisioning profile value to "Automatic" in the build settings editor.
It seems I need to decompose the 'test' action to build the library without the profile, but everything else with the profile, and then trigger testing.
Can this 'xcodebuild test' command be rewritten as several commands to effect such a build/test? I need a command-line solution because this is part of a continuous integration.
Thanks in advance!
This happened to me using manual signing and including Cocoapods dependencies. This is possibly a known issue with Cocoapods (https://github.com/CocoaPods/CocoaPods/pull/6964). Their workaround is to specify setting PROVISIONING_PROFILE_SPECIFIER to '' in the Podfile's post_install hook, but this didn't work for us because we commit our Pods, so the post_install hook doesn't run when we build.
However, in addition to passing the option PROVISIONING_PROFILE_SPECIFIER=xxxxx to xcodebuild, we were able to build by setting the following options in Pods.xcodeproj/project.pbxproj for each target/build configuration:
CODE_SIGNING_ALLOWED = NO;
CODE_SIGNING_REQUIRED = NO;
PROVISIONING_PROFILE = '';
PROVISIONING_PROFILE_SPECIFIER = '';
I am not primarily an iOS developer by trade, but from my understanding, PROVISIONING_PROFILE is deprecated and specifying both CODE_SIGNING_ALLOWED and CODE_SIGNING_REQUIRED may be redundant, but we do it anyway at the moment in our project.
Try using PROVISIONING_PROFILE_SPECIFIER=xxxxx instead of setting PROVISIONING_PROFILE, which is deprecated starting with Xcode8.
If the error then still occurs, try to set neither DEVELOPMENT_TEAM nor PROVISIONING_PROFILE_SPECIFIER, as these codesigning related buildsettings are only relevant, if you are actually building an app (but you are only executing an xcodebuild test on an already build app bundle).
If you want to build and test the app with one call of xcodebuild, you are encouraged to do a xcodebuild ... clean build test
EDIT
After taking a look at the WebDriverAgent project, the problem is related to the WebDriverAgentLib being a Dynamic Framework and a Target-Dependency of the WebDriverAgentRunner-Bundle. Dynamic Frameworks don't like codesigning during the build phase in Xcode8 at all (they now should be codesigned on the fly when being copied into the build product). With specifying code signing related build settings on the command line (DEVELOPMENT_TEAM etc.), Xcode8 will complain about this for Dynamic Framework targets and fail the build.
Solution 1: remove all codesigning related build settings from your xcodebuild call (PROVISIONING_PROFILE_SPECIFIER, PROVISIONING_PROFILE, DEVELOPMENT_TEAM, CODE_SIGN_IDENTITY) and just set these for the WebDriverAgentRunner-Target (either in the Xcode UI or via Command-Line with plistbuddy on the project.pbxproj).
Solution 2: don't test on a real device and instead just on the Simulator. As there is no need to codesign an Executable and/or Test-Bundle for Simulators, you can safely omit any codesigning related parameters from your xcodebuild call.
Solution 3: just stick with Automatic CodeSigning and assure that there a is valid login for the proper Developer Account in the build machine's Xcode.
I had this error and https://stackoverflow.com/a/39923121/713391 suggested i check "Enable Automatic Signing" then click cancel without doing anything, which did fix it. A code diff showed the change was to add
ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES;
or in Xcode it's called Always Embed Swift Standard Libraries
I have a project that has multiple different targets/schemes (~38 of them as of writing this question) and I am trying to get unit testing working properly across all of the different targets. I got things working with one target, and tried adding my testing target to all of the different schemes, but it looks like when tests run for each scheme they actually run on the same, original target.
Looking in the project file I see that there's a specific Host Application associated with my testing target, and in the build settings the Bundle Loader and Test Host point to that same Host Application.
Is there any way to override those values for each scheme to run the tests against the current scheme's build target? Or some other way to set up a single test target to run across multiple build targets?
If you run the tests from the command line, or from an CI tool, like Jenkins, you can instruct xcodebuild to use the build settings that you provide. A simple usage example would be:
xcodebuild -scheme SomeScheme test TEST_HOST=target
You can control almost (if not any) build setting from Xcode, like code coverage generation, build directory, derived data directory, code sign identity, etc.
You can select the scheme when you run tests with Xcode server.
Look at WWDC 2014 continues integration talk for a walk through on how to set it up
https://developer.apple.com/videos/play/wwdc2014-415/
It's using Xcode 6 but it's very similar process to Xcode 7
Also check this CI(continues integration) guideline from apple
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/xcode_guide-continuous_integration/adopt_continuous_integration.html
If anyone is wondering how to do that with UI tests (maybe it is working with unit tests, too), this is what I came up with:
First, we need to build the application which we are going to use to host our UI tests:
xcodebuild -scheme "<appSchemeName>" build -destination "<yourDestination>"
More info about destination parameter: https://mokacoding.com/blog/xcodebuild-destination-options/
Then, we need to run tests on our newly built application:
xcodebuild -scheme "<uiTestsSchemeName>" -destination "<yourDestination>" test TEST_TARGET_NAME="<yourNewlyBuiltAppTargetName>"
Destinations should match, since after the build .app is generated in your DerivedData folder, which will be used for UI tests hosting application
I'm facing with this error:
command:
xcodebuild test -scheme Exclusive -destination "platform=iOS"
result:
xcodebuild: error: Scheme Exclusive is not currently configured for the test action.
My scenario: 3 targets, 3 schemas. One target for each theme. So I need to run UI test for each target.
What I'm doing wrong?
EDIT:
It sounds like the Exclusive scheme doesn't include a test target. You can add/remove them by double-clicking on the scheme name in the Manage Schemes window.
Then click the + in the bottom to add your testing target(s).
I'm trying to build my XCode project via the terminal. I'd like use Xcode's Product > Build for > Profiling option. So far I have:
xcodebuild -project "MyGame.xcodeproj" -target "MyGameEditor - Mac" -destination 'name=My Mac 64-bit' -configuration Profile
The project builds but not for profiling. I get an error that configuration 'Profile' does not exist.
Any help is appreciated.
What you are trying to sepcify with -configuration is the build configuration, not the build action. Unless you have added extra configurations to your project, you only have "Debug" and "Release" configurations.
What Xcode does when you tell it to profile is it builds the configuration that your scheme specifies to use when profiling, launches the simulator, installs the app, then launches Instruments.
So you need to do a similar thing with two command line calls, one to xcodebuild, one to instruments.
Some helpful links that should help you figure out what you need to do:
http://blog.manbolo.com/2013/04/09/launching-uiautomation-tests-in-command-line
Can the UI Automation instrument be run from the command line?
It is also worth noting that rather than specifying a target and configuration, you should just specify a scheme which provides both and other optional additional features.