fastlane: Could not find a matching code signing identity for type 'AdHoc'. You can use cert to generate one
New Issue Checklist
- Updated fastlane to the latest version
- I read the Contribution Guidelines
- I read docs.fastlane.tools
- I searched for existing GitHub issues
Issue Description
Complete output when running fastlane, including the stack trace and command used
No existing profiles found, that match the certificates you have installed locally! Creating a new provisioning profile for you WARN [2017-12-07 18:10:40.07]: No certificates for filter: Certificate ID: ‘NGMBD6E3T8’ ERROR [2017-12-07 18:11:40.09]: Unable to send the crash report. ERROR [2017-12-07 18:11:40.09]: Please open an issue on GitHub if you need help!
Environment
fastlane --version 2.68.0 match 2.68.0 sigh 2.68.0
this is a enterprise account
match(type: “#{type}”, verbose: true, force: true, app_identifier: “#{app_identifier}”, git_branch: ENV[‘MATCH_INHOUSE_BRANCH’], clone_branch_directly: true, force_for_new_devices: true, provisioning_name: “#{provisioning_name}”, username: “dlxdell@hotmail.com”, team_id: “SHDWRXPG6N”)
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 19 (10 by maintainers)
Hey all 👋 I made what I think is a fix for how
matchwill handle enterprise adhoc-ness ^ If you want to check it out that would be ❤️I was able to figure it out! Turns out the bug is in Sigh and how it uses Spaceship.
First, to get certs, there’s a call to
https://developer.apple.com/services-account/PLATFORM_ID/account/ios/certificate/listCertRequests.actionthat happens. The parameters for that request areteamId,pageSize,pageNumber,sort, andtypes. For enterprise accounts (note: accounts, not certificates or profiles, the entire account/team is an In-House team), when you query this endpoint after authenticating with a value ofR58UK2EWSOfortypes, which is the certificate identifier that Spaceship has defined forProductionin this mapping:the list returns empty so it was failing despite the certificate existing in the developer portal. I went through and tried a couple different ones and it turns out if you’re trying to fetch an adhoc certificate from an enterprise account, you can get it but only if the value of
typesis9RQEK7MSXAor InHouse. The fix is really easy actually, I just added this:in this method (runner.rb: 172, the last
elsifclause underios, tvos):When that happens, both the adhoc and enterprise certificate we use returned from the API call and match was able to set up adhoc certificates successfully. I can put up a PR that fixes this if that sounds good @KrauseFx @joshdholtz
This has not been fixed and there is a code proposed as fix. It looks to me that a maintainer has to decide if it makes sense to add that code.
@polmum Thanks for linking that! Will look into 👀
Feedback please?
Is this fixed and released? I’m having the same issue with an enterprise account generating AdHoc profile.