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
          kazuhidet Kazuhide Takahashi added a comment -

          I posted a PR of the version which treated pointed developmentTeamID, trouble of -allowProvisioningUpdates, and various other modifications.
          You can download the snapshot that applied this change from the following URL, so if you can, please test with this.
          https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fxcode-plugin/detail/PR-94/11/artifacts

          Show
          kazuhidet Kazuhide Takahashi added a comment - I posted a PR of the version which treated pointed developmentTeamID, trouble of -allowProvisioningUpdates, and various other modifications. You can download the snapshot that applied this change from the following URL, so if you can, please test with this. https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fxcode-plugin/detail/PR-94/11/artifacts
          Hide
          stephanwezelps Stephan Wezel added a comment -

          Looks good. For the development team part.
          I cannot test the "allowProvisioningUpdates" part because we don't use xcode < 9

          Another problem i see is how the manual signing configuration is currently handled.
          Currently you have to specify the bundle id in the jenkins configuration.

          For manual signing with xcode-plugin <=2.0.0 i use a shell script which first gets the bundle id from the xcode project via following command:
          /usr/libexec/PlistBuddy -c "Print :ApplicationProperties:CFBundleIdentifier" "${WORKSPACE}/output/ios/build/Unity-iPhone.xcarchive/Info.plist"

          It would be create when the xcode-plugin would offer such an option as well.

          This would avoid the need to update the jenkins configuration when the bundle id gets changed in the source project.

          Show
          stephanwezelps Stephan Wezel added a comment - Looks good. For the development team part. I cannot test the "allowProvisioningUpdates" part because we don't use xcode < 9 Another problem i see is how the manual signing configuration is currently handled. Currently you have to specify the bundle id in the jenkins configuration. For manual signing with xcode-plugin <=2.0.0 i use a shell script which first gets the bundle id from the xcode project via following command: /usr/libexec/PlistBuddy -c "Print :ApplicationProperties:CFBundleIdentifier" "${WORKSPACE}/output/ios/build/Unity-iPhone.xcarchive/Info.plist" It would be create when the xcode-plugin would offer such an option as well. This would avoid the need to update the jenkins configuration when the bundle id gets changed in the source project.
          Hide
          kazuhidet Kazuhide Takahashi added a comment - - edited

          Stephan Wezel

          Basically the codesign to the IPA file with the current Xcode Plugin is almost the same as that described in this article.

          Code Signing Updates in Xcode 9

          https://possiblemobile.com/2017/09/xcode-9-code-signing-updates/

          As this article also states, in current Xcode it is necessary to create exportOptions.list to codesign and set various options, a combination of provisioning profile and Bindle ID of the application etc in it .

          Then pass it to xcodebuild's '-exportOptionsPlist' and export IPA from xcarchive.
          Override the settings using PROVISIONING_PROFILE_SPECIFIER or CODE_SIGN_IDENTITY that was possible in Xcode 8 and earlier is no longer possible.

          Therefore, if you want to export an IPA file based on the information of an existing archive, you can use a script like the following example, or use information obtained by using a script similar to this by some means (for example, EnvInject Plugin) To pass to the Xcode plugin and respond.

          EasyIPAExporter

          Alternatively, you can get information on code signatures from Xcode's project file as I suggested previously (in PR #91) and use it for exportOptioins.plist.
          This is functioning very well so far, but it seems to require a bit more testing and correct bugs.

          Show
          kazuhidet Kazuhide Takahashi added a comment - - edited Stephan Wezel Basically the codesign to the IPA file with the current Xcode Plugin is almost the same as that described in this article. Code Signing Updates in Xcode 9
 https://possiblemobile.com/2017/09/xcode-9-code-signing-updates/ 
 As this article also states, in current Xcode it is necessary to create exportOptions.list to codesign and set various options, a combination of provisioning profile and Bindle ID of the application etc in it .
 Then pass it to xcodebuild's '-exportOptionsPlist' and export IPA from xcarchive. Override the settings using PROVISIONING_PROFILE_SPECIFIER or CODE_SIGN_IDENTITY that was possible in Xcode 8 and earlier is no longer possible. Therefore, if you want to export an IPA file based on the information of an existing archive, you can use a script like the following example, or use information obtained by using a script similar to this by some means (for example, EnvInject Plugin) To pass to the Xcode plugin and respond. EasyIPAExporter Alternatively, you can get information on code signatures from Xcode's project file as I suggested previously (in PR #91 ) and use it for exportOptioins.plist. This is functioning very well so far, but it seems to require a bit more testing and correct bugs.
          Hide
          stephanwezelps Stephan Wezel added a comment -

          Kazuhide Takahashi

          I don't understand what do you try to tell me.

          My wish is that the xcode-plugin grabs optionally the bundle-id from the build xcode archive for manual signing instead of the need to specify the bundle id in the xcode-plugin configuration.

          As already mentioned this option would avoid to update the xcode-plugin configuration of a jenkins job when the bundle id gets changed in the project which gets build by the jenkins job.

          The xcode-plugin has already an option to change the bundle-id before building the archive via xcode.
          We would only need a reverse version which fetches the bundle-id from the xcode archve Info.plist file.

          Show
          stephanwezelps Stephan Wezel added a comment - Kazuhide Takahashi I don't understand what do you try to tell me. My wish is that the xcode-plugin grabs optionally the bundle-id from the build xcode archive for manual signing instead of the need to specify the bundle id in the xcode-plugin configuration. As already mentioned this option would avoid to update the xcode-plugin configuration of a jenkins job when the bundle id gets changed in the project which gets build by the jenkins job. The xcode-plugin has already an option to change the bundle-id before building the archive via xcode. We would only need a reverse version which fetches the bundle-id from the xcode archve Info.plist file.
          Hide
          kazuhidet Kazuhide Takahashi added a comment -

          Stephan Wezel
          Certainly, as you say, if you have only one application, you can replace the simple Bundle ID implemented in the current plugin, but in fact this method does not work well.
          This is because if you write an application that supports WatchKit, for example, the application has three Bundle IDs, WatchKit App and Watch Kit Extension, in addition to the main application, and Info.plist exists in each of these It is.

          Therefore, if you want to correctly change the Bundle ID even in such a case, the correspondence table for each of these Bundle IDs is new and old.

          For now, I have not come up with a way to respond well to this problem.
          So I suggested the method that I wrote in the message the last day, but do you have any idea to handle something well?
          If there is a nice way, I would like to solve this problem by incorporating that idea.

          Show
          kazuhidet Kazuhide Takahashi added a comment - Stephan Wezel Certainly, as you say, if you have only one application, you can replace the simple Bundle ID implemented in the current plugin, but in fact this method does not work well. This is because if you write an application that supports WatchKit, for example, the application has three Bundle IDs, WatchKit App and Watch Kit Extension, in addition to the main application, and Info.plist exists in each of these It is. Therefore, if you want to correctly change the Bundle ID even in such a case, the correspondence table for each of these Bundle IDs is new and old. For now, I have not come up with a way to respond well to this problem. So I suggested the method that I wrote in the message the last day, but do you have any idea to handle something well? If there is a nice way, I would like to solve this problem by incorporating that idea.
          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: