Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
xcode-plugin 2.0.2
jenkins 2.107.3
Description
The changes for fixing Bug JENKINS-47744, JENKINS-45509
With
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
stephanwezelps
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
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
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 The automatic signing test was also an success.
For me the bug seems to be fixed with the changes in PR-94
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 This problem has been resolved because we imported a fix for PR # 94 in version 2.0.3.
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