fix: renew provisioning profiles by exact name, for both app and extension targets
The prior force:true fix only touched the main app's profile and let sigh name it '<bundle id> AppStore' - a different name than the one manual signing expects (PROVISIONING_PROFILE_SPECIFIER = 'LC Prov PediFoods Dist Profile' / 'LC Prov PediFoods Dist Push Profile', baked into PediFoods.xcodeproj per target). Xcode resolves profiles by exact Name match against installed .mobileprovision files, so it never found sigh's freshly-created one and kept falling back to the stale, wrong-certificate profile under the old name - the extension's profile was never touched at all, since sigh only acts on the app_identifier it's given. Added renew_provisioning_profiles (shared by beta and release), calling get_provisioning_profile once per target with an explicit provisioning_name matching what the project actually expects, plus force: true so each is regenerated against the team's current certificates.
This commit is contained in:
@@ -34,20 +34,38 @@ lane :assemble do |options|
|
|||||||
)
|
)
|
||||||
end
|
end
|
||||||
|
|
||||||
|
# Manual signing (PROVISIONING_PROFILE_SPECIFIER baked directly into
|
||||||
|
# PediFoods.xcodeproj's build settings, per target) means Xcode resolves
|
||||||
|
# a profile by matching that exact Name string against installed
|
||||||
|
# .mobileprovision files - not by bundle identifier alone. Without an
|
||||||
|
# explicit provisioning_name:, sigh names a freshly (re)created profile
|
||||||
|
# "<bundle identifier> AppStore" by default, which doesn't match the
|
||||||
|
# project's expected names ("LC Prov PediFoods Dist Profile" / "LC Prov
|
||||||
|
# PediFoods Dist Push Profile") - Xcode then can't find it and falls
|
||||||
|
# back to whatever stale profile happens to already be installed under
|
||||||
|
# the old name, which is exactly the doesn't-include-this-cert error
|
||||||
|
# force: true alone didn't fix. Also needs one call per target: sigh
|
||||||
|
# only touches the app_identifier it's given, and the
|
||||||
|
# NotificationServiceExtension has its own separate bundle id.
|
||||||
|
private_lane :renew_provisioning_profiles do
|
||||||
|
get_provisioning_profile(
|
||||||
|
api_key_path: "fastlane/apikey.json",
|
||||||
|
app_identifier: "com.br.pedifoods.app",
|
||||||
|
provisioning_name: "LC Prov PediFoods Dist Profile",
|
||||||
|
force: true
|
||||||
|
)
|
||||||
|
get_provisioning_profile(
|
||||||
|
api_key_path: "fastlane/apikey.json",
|
||||||
|
app_identifier: "com.br.pedifoods.app.NotificationService",
|
||||||
|
provisioning_name: "LC Prov PediFoods Dist Push Profile",
|
||||||
|
force: true
|
||||||
|
)
|
||||||
|
end
|
||||||
|
|
||||||
lane :beta do |options|
|
lane :beta do |options|
|
||||||
desc "Build and upload to TestFlight"
|
desc "Build and upload to TestFlight"
|
||||||
|
|
||||||
# force: true - without it, sigh just downloads whatever profile
|
renew_provisioning_profiles
|
||||||
# already exists on Apple's servers as-is. This CI keychain's
|
|
||||||
# distribution certificate is a different one than whatever the
|
|
||||||
# existing profile was last generated against, so a plain (non-forced)
|
|
||||||
# fetch produced a profile that doesn't include this machine's cert -
|
|
||||||
# "Provisioning profile ... doesn't include signing certificate
|
|
||||||
# 'iPhone Distribution: Loverde Company LTDA (K4E5BZMM4V)'" at archive
|
|
||||||
# time. Forcing a renewal makes sigh regenerate the profile against
|
|
||||||
# the team's currently valid certificates instead of reusing a stale
|
|
||||||
# one.
|
|
||||||
get_provisioning_profile(api_key_path: "fastlane/apikey.json", force: true)
|
|
||||||
|
|
||||||
assemble
|
assemble
|
||||||
|
|
||||||
@@ -65,17 +83,7 @@ lane :release do |options|
|
|||||||
|
|
||||||
# if you have an apikey.json file (https://developer.apple.com/documentation/appstoreconnectapi/creating-api-keys-for-app-store-connect-api), fastlane can automatically fetch certificates and the ASC authentication information
|
# if you have an apikey.json file (https://developer.apple.com/documentation/appstoreconnectapi/creating-api-keys-for-app-store-connect-api), fastlane can automatically fetch certificates and the ASC authentication information
|
||||||
#get_certificates(api_key_path: "fastlane/apikey.json")
|
#get_certificates(api_key_path: "fastlane/apikey.json")
|
||||||
# force: true - without it, sigh just downloads whatever profile
|
renew_provisioning_profiles
|
||||||
# already exists on Apple's servers as-is. This CI keychain's
|
|
||||||
# distribution certificate is a different one than whatever the
|
|
||||||
# existing profile was last generated against, so a plain (non-forced)
|
|
||||||
# fetch produced a profile that doesn't include this machine's cert -
|
|
||||||
# "Provisioning profile ... doesn't include signing certificate
|
|
||||||
# 'iPhone Distribution: Loverde Company LTDA (K4E5BZMM4V)'" at archive
|
|
||||||
# time. Forcing a renewal makes sigh regenerate the profile against
|
|
||||||
# the team's currently valid certificates instead of reusing a stale
|
|
||||||
# one.
|
|
||||||
get_provisioning_profile(api_key_path: "fastlane/apikey.json", force: true)
|
|
||||||
|
|
||||||
assemble
|
assemble
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user