Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-51418

Automatic signing broken with version 2.0.2 and xcode 9

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: xcode-plugin
    • Labels:
    • Environment:
      xcode-plugin 2.0.2
      jenkins 2.107.3
    • Similar Issues:

      Description

      The changes for fixing Bug JENKINS-47744JENKINS-45509

      With

      PR #86, PR#87

      Automatic signing is broken with xcode 9. Because with those changes the development team isn't given to the xcode commandline in automatic signing mode.

      The development team must be always given to the xcode commandline regardless if automatic signing is used or not!

      In Manual signing mode only an provisioning profile must be provided additional to the teamid.

      The selection of the development team should be restored to the old behaviour.

       
      E.g. the code in XCodeBuilder.java should be changed from

       

      // handle code signing identities
      if (manualSigning != null && manualSigning && !StringUtils.isEmpty(developmentTeamID)) {
          commandLine.add("DEVELOPMENT_TEAM=" + developmentTeamID);
          xcodeReport.append(", developmentTeamID: ").append(developmentTeamID);
      } else {
          commandLine.add("-allowProvisioningUpdates");
          xcodeReport.append(", developmentTeamID: AUTOMATIC");
      }
      

      to something like this (untestet)

       

      // handle code signing identities
      if (!StringUtils.isEmpty(developmentTeamID)) {
          commandLine.add("DEVELOPMENT_TEAM=" + developmentTeamID);
          xcodeReport.append(", developmentTeamID: ").append(developmentTeamID);
      } else {
          xcodeReport.append(", developmentTeamID: DEFAULT");
      }
      
      // Handle provisioning profile
      if (manualSigning == null || !manualSigning) {
          commandLine.add("-allowProvisioningUpdates");
      }
      

       The  "-allowProvisioningUpdates" option exists only in xcode >= 9 This will break usage of the plugin with xcode < 9

        Attachments

          Activity

          Hide
          stephanwezelps Stephan Wezel added a comment -

          Ah the multiple bundle-id case didn't come to mine mind. Currently we don't have such a case.

          I could imagine following:
          Instead of specifing the bundle-id the user could specify the path to the plist file, which contains the bundle-id.
          e.g. "${WORKSPACE}/output/ios/build/Unity-iPhone.xcarchive/Info.plist"

          Then the plugin could fetch the bundle-id from the plist file for the specified mobile provisioning file/ID.

          I would guess that even for the multible bundle-id case with e.g. WatchKit, the bundle ids must be located in separated plist files in the generated xcode xcarchive when applying the mobile provisioning profiles. Otherwise the signing/applying the mobile provisioning profiles would fail when the build result itself would not contain the bundle-ids

          Show
          stephanwezelps Stephan Wezel added a comment - Ah the multiple bundle-id case didn't come to mine mind. Currently we don't have such a case. I could imagine following: Instead of specifing the bundle-id the user could specify the path to the plist file, which contains the bundle-id. e.g. "${WORKSPACE}/output/ios/build/Unity-iPhone.xcarchive/Info.plist" Then the plugin could fetch the bundle-id from the plist file for the specified mobile provisioning file/ID. I would guess that even for the multible bundle-id case with e.g. WatchKit, the bundle ids must be located in separated plist files in the generated xcode xcarchive when applying the mobile provisioning profiles. Otherwise the signing/applying the mobile provisioning profiles would fail when the build result itself would not contain the bundle-ids
          Hide
          kazuhidet Kazuhide Takahashi added a comment -

          Stephan Wezel
          I see !
          That is a good idea.
          I incorporated that idea immediately.

          • If Profile UUID  is an .mobileprovision file, obtain the profile UUID from .mobileprovision and use it.
          • If App Id is an Info.plist file, obtain the Bundle ID from Info.plist and use it.

          Snapshots can be get from the following URL.
          https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fxcode-plugin/detail/PR-94/13/artifacts

          Show
          kazuhidet Kazuhide Takahashi added a comment - Stephan Wezel I see ! That is a good idea. I incorporated that idea immediately. If Profile UUID  is an .mobileprovision file, obtain the profile UUID from .mobileprovision and use it. If App Id is an Info.plist file, obtain the Bundle ID from Info.plist and use it. Snapshots can be get from the following URL. https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fxcode-plugin/detail/PR-94/13/artifacts
          Hide
          stephanwezelps Stephan Wezel added a comment -

          Looks good the extension. For now only tested manual signing with specifying the provisioning profile via UUID (selectable via the Keychains and Provisioning Profiles Management plugin) and specifiying the path to the plist file in the xcarchive which contains the bundle id.

          Will test automatic signing later

          Show
          stephanwezelps Stephan Wezel added a comment - Looks good the extension. For now only tested manual signing with specifying the provisioning profile via UUID (selectable via the Keychains and Provisioning Profiles Management plugin) and specifiying the path to the plist file in the xcarchive which contains the bundle id. Will test automatic signing later
          Hide
          stephanwezelps Stephan Wezel added a comment - - edited

          The automatic signing test was also an success.
          For me the bug seems to be fixed with the changes in PR-94

          Show
          stephanwezelps Stephan Wezel added a comment - - edited The automatic signing test was also an success. For me the bug seems to be fixed with the changes in PR-94
          Hide
          kazuhidet Kazuhide Takahashi added a comment -

          This problem has been resolved because we imported a fix for PR # 94 in version 2.0.3.

          Show
          kazuhidet Kazuhide Takahashi added a comment - This problem has been resolved because we imported a fix for PR # 94 in version 2.0.3.

            People

            • Assignee:
              kazuhidet Kazuhide Takahashi
              Reporter:
              stephanwezelps Stephan Wezel
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: