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-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
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