azure-pipelines-tasks: Xcode@5 Code Signing Error when building a project with embedded framework that does not support manual signing

@pandey-laxman, sorry missed this email!

It needs to go in the arguments field in the Xcode task. This is how my Xcode task looks (in yaml):

          - task: Xcode@5
            inputs:
              actions: 'build'
              xcWorkspacePath: '**/myproj.xcworkspace'
              scheme: 'myproj'
              xcodeVersion: 'specifyPath'
              xcodeDeveloperDir: '/Applications/Xcode_11.1.app'
              packageApp: true
              exportPath: 'output/$(SDK)/$(BuildConfiguration)'
              exportOptions: 'plist'
              exportOptionsPlist: 'pipelines/export.debug.plist'
              signingOption: 'manual'
              signingIdentity: '$(APPLE_CERTIFICATE_SIGNING_IDENTITY)'
              provisioningProfileUuid: '$(APPLE_PROV_PROFILE_UUID)'
              args: 'CODE_SIGNING_ALLOWED=No'

Hi, @ericallam

The problem that you experience is specific for Unity Framework, our task is a more generic tool and we don’t plan to support specific frameworks like Unity. If it is required to build Unity Framework we could suggest you implement the task for this by yourself, which will consider Unity-specific features and options. Introducing any changes for support of specific frameworks in the existing Xcode task will make it more complex and also it would take effort to keep the task in sync with new framework versions. We don’t want to complicate the existing task structure by introducing framework-specific logic.

Although workarounds are described above, it would be nice is this issue would be fixed in this official repo. Are there any updates? Is this issue prioritized, and/or will it be?

For me, CODE_SIGNING_ALLOWED=No allowed my build to complete, but I couldn’t use the resulting app because it wasn’t signed. So, I don’t believe that’s a good solution.

Edit: this did not end up being the final solution, see my new comment below for the full build script that uses separate archive/export archive steps.

Wish msft had more customer empathy with this kind of thing. Yes, this task isn’t specific to Unity, but it is specific to xcode, and Unity is a common framework to build in xcode. I agree it probably doesn’t warrant an implementation change on your side, but even mentioning something in your docs about how to work around this would be helpful because it is still an issue, rather than simply saying “not our problem”.

The original solution of using PROVISIONING_PROFILE_APP and PROVISIONING_PROFILE_SPECIFIER_APP here worked for me, and everything builds/signs successfully. I ended up just using a bash script because at the end of the day this task is really only useful for learning what xcodebuild runs under the hood… because even passing manual args doesn’t work correctly as you can see above in some other replies.

Here is the relevant section of the pipeline to show more explicitly how to work around this. See this doc on signing if you need context on how to use/setup the InstallAppleCertificate@2 and InstallAppleProvisioningProfile@1 tasks.

- task: InstallAppleCertificate@2
  inputs:
    certSecureFile: '$(certFileInSecureLibrary)'
    certPwd: '$(cert_password)'
    keychain: temp
    deleteCert: true
 
- task: InstallAppleProvisioningProfile@1
  inputs:
    provisioningProfileLocation: 'secureFiles'
    provProfileSecureFile: '$(yourProfileFile)'
    removeProfile: true

- task: Bash@3
  inputs:
    targetType: inline
    script: >
      /usr/bin/xcodebuild
      -sdk iphoneos
      -configuration Release
      -project $(xcodeRoot)/Unity-iPhone.xcodeproj
      -scheme Unity-iPhone
      build
      CODE_SIGN_STYLE=Manual
      CODE_SIGN_IDENTITY='$(APPLE_CERTIFICATE_SIGNING_IDENTITY)'
      PROVISIONING_PROFILE_APP=$(APPLE_PROV_PROFILE_UUID)
      PROVISIONING_PROFILE_SPECIFIER_APP=your-provisioning-profile-name
      CONFIGURATION_BUILD_DIR=$(xcodeRoot)/build-output/

In this example, the variable $(xcodeRoot) is set to $(Pipeline.Workspace)/s because in our case we aren’t cloning a repo in this job, we pull down the Unity xcode project files from a preceding job that runs on a windows VM, and manually put it in the dir where AzDo normally expects your repo root to be e.g. /Users/runner/work/1/s/.

Additionally, because we were building the xcode project files on a windows box, there is one other task we needed. There are two shell scripts in the xcode project root that were getting permission denied errors, so you can simply just add a bash task to chmod them first before running your xcodebuild script:

- task: Bash@3
  displayName: 'chmod shell scripts in xcode project root'
  inputs:
    targetType: inline
    script: |
      chmod +x $(xcodeRoot)/MapFileParser.sh
      chmod +x $(xcodeRoot)/process_symbols.sh

Just a quick update, we tried your task and specified the suffix of APP, but it didn’t seem to make any difference to the build. I also tried it locally and couldn’t get xcodebuild to do anything with PROVISIONING_PROFILE_APP. It did the same as if it wasn’t specified.

Anyway, we found that using the original Xcode build task and specifying an argument of “CODE_SIGNING_ALLOWED=No” made it all build and sign correctly.

Thanks for you help.

The work around we used was to use a custom bash task that would execute all the commands that the xcode task would do, but with our own arguments.

You can find what all the commands are by observing the logs or outputs from the xcode task.

I am experiencing the same problem when upgrading from Unity 2018.4 to 2020.3 and it is a show stopper for automatic builds. A solution to this problem would be appreciated!