7

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!

android.weasel
  • 3,343
  • 1
  • 30
  • 41

3 Answers3

9

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.

Chris Knepper
  • 146
  • 1
  • 3
3

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.

Sven Driemecker
  • 3,421
  • 1
  • 20
  • 22
  • Thanks for such a full answer. I gave up in disgust and opted for 3: while I build the app with the user 'qa', I run the tests in parallel on several devices for which I need to use users 'qa1', 'qa2', etc, so 'qa1', 'qa2', only ever received a copy of qa's primary app build, and could be made to use automatic signing for the test framework. I remain deeply unimpressed that Apple's system demands NO provisioning profile for the library, not ignoring it like most other software would, perhaps with a warning. Also unimpressed that I need qa1, 2 to have a desktop active for automatic signing. – android.weasel Oct 12 '16 at 07:30
  • 2
    Yeah Apple really took a step backwards with Automatic Codesigning and all the new restrictive Codesigning rules. That stuff is just suitable for the usual independent Developer working on one iMac with one Xcode, having one Developer-Account and only a few apps. But it's a big mess for every company dealing with continuous integration, automated testing, complex project structures and/or multiple codesigning identities... – Sven Driemecker Oct 12 '16 at 07:48
0

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

Community
  • 1
  • 1
tristanl
  • 21
  • 5