This is a companion discussion topic for the original entry at https://www.raywenderlich.com/1259223-fastlane-for-ios/lessons/13
This is a companion discussion topic for the original entry at https://www.raywenderlich.com/1259223-fastlane-for-ios/lessons/13
Hi, I have problem with Adhoc license using match. I got an error for “iCloudContainerEnvironment” key. When I run app store license using match, everything is working fine while export.
I haven’t personally encountered this kind of issue, but fastlane support shows this has been an issue for some people. It looks like the problem usually boils down to having a mismatch between the environment selected (say, “development”) and the type of action being required (e.g., “app store”). That said, I can’t find any references at all to people having this problem when running match (every support issue I could find for this was related to another fastlane tool called gym, which we cover in Section 3).
Can you check to make sure that you nuked your existing Certificates and then try running fastlane match adhoc once again? If the problem persists, I’ll be happy to work with you in submitting an issue to the fastlane team, which is typically quite responsive and helpful!
Thank you for swift response.
I tried many times even after nuke. “iCloudContainerEnvironment” didn’t include automatically for Adhoc but it works flawlessly with AppStore.
I saw my cert in developers portal and it does include iCloud value in cert.
Hmmm… I know this is a bit redundant, but just to confirm, this happens when you run fastlane match adhoc, but both fastlane match development and fastlane match App Store work as expected for you?
Yes, for me i only happened when i run fastlane match adhoc and then build with adhoc.
That might point us in a direction I can help with. When you say “…and then build with adhoc”, do you mean using gym? Specifically, it sounds like maybe the command fastlane match adhoc doesn’t throw this error in itself, but rather that you get this error when you invoke gym. Is that right?
Yes, You are right. I got error when build with adhoc using gym.
I’m unable to add another reply so i’m adding comments for below post.
Hi, I appreciate your efforts and swift response. I already tried it but the problem is after using manual export_options it overrides match settings.
I also read in documentation if you are using match you don’t need to mention export_options.
Great! Now that I know this issue occurs with gym I think we can resolve your issue. 
If you do some web searching, you can find several people reporting issues using gym with ad hoc certificates. Here’s 2 examples:
Generally, the resolution of your issue comes down to providing gym a bit more information, so it can correctly select the right assets to use. Specifically, I’d suggest adding this to your ad hoc gym command:
gym(
…
export_method: "ad-hoc",
export_options: {iCloudContainerEnvironment: 'Production']}
)
As usual, you can dig a bit deeper and learn more about how to tune gym via its documentation page. Good luck!
So, I would like to follow your best practice of creating a separate Apple ID to use with match, and I can’t nuke all the certificate on my existing Apple ID anyway because I’m using it for a bunch of other projects in which I haven’t integrated Fastlane yet. But does that mean I should also take a separate iOS developer subscription for that separate Apple ID too?
Great question. I think in your case, the answer’s more nuanced than a simple yes or no. If you had access to a team account, then I’d absolutely advise created a new use account under that. And again, If you didn’t have the investment in your non-match certs, it’d again be a no-brainer. But the choice isn’t as simple or clear in your situation, where you can’t simply nuke your existing code-signing assets.
Generally, the main reasons to nuke existing certs in a personal account is to keep things clean and simple, and to ensure that you don’t develop subtle problems in which, say, a personal certificate might mask your match certificate. But if you don’t run nuke, it doesn’t necessarily mean that you will have problems – just that you might, and that you’ll likely need to exercise more awareness of which signing assets are doing what.
So long as you don’t mind keeping a tighter eye on these things, I’d probably suggest trying using match with your existing account, of course keeping your existing certs in place. Odds are decent that everything will just work. If you do run into problems, you can always work with fastlane support to resolve, or decide then if it’s worth creating and paying for a separate account.
Hope that helps…
OK thanks. Another question though: what is this technicality you mentioned that prevented fastlane to prompt you from a passphrase? Because I made a mistake when running match the first time: I thought it was asking for my Github password and so I used my Github password as an encryption passphrase. So I tried to reset everything so that it asks me for the passphrase again but it doesn’t anymore. So how can I reset this stored password so that I can use one specific to this?
I figured it out thanks to the documentation. All I had to do was to run the following command:
fastlane match change_password
@sarbogast Really glad you fixed it! Cheers! :]
"type"<uint32>=<NULL>
password has been deleted.
[13:36:28]: Enter the passphrase that should be used to encrypt/decrypt your certificates
[13:36:28]: This passphrase is specific per repository and will be stored in your local keychain
[13:36:28]: Make sure to remember the password, as you’ll need it when you run match on a different machine
[13:36:28]: Passphrase for Git Repo:
I am stuck on this error. help
@brian_bee I am stuck at fastlane match development. help please
"type"<uint32>=<NULL>
password has been deleted.
[13:36:28]: Enter the passphrase that should be used to encrypt/decrypt your certificates
[13:36:28]: This passphrase is specific per repository and will be stored in your local keychain
[13:36:28]: Make sure to remember the password, as you’ll need it when you run match on a different machine
[13:36:28]: Passphrase for Git Repo:
There’s a lot I can’t tell about your local, git, and fastlane environments and the specific commands/lanes you’re running from your comment. But based on what you have reported, it appears you’re likely encountering an edge case that was reported last year and reported as resolved in a subsequent update. The specific fastlane command that prompted the error was fastlane match change_password
Interestingly, I do also find a newer issue where a user reports a very similar issue. However, this time, the issue was closed without any change to code. Happily, the exchange between the poster and fastlane team member points the way to a potential solution:
I think this is happening when the certificate repo is empty.
That would make sense, probably nobody even checked that to be honest as the password encrypts individual files … [but] how we should actually fix this? Should it exit with a “your repo is empty, no password set yet to change” warning early or should we let you input everything as right now and then just not crash as it does right now?
I’d suggest (a) making sure that you’re running the current version of fastlane, and then (b) taking a look at these posts to see if the empty repo case described matches your case. Let me know how that goes, and I’ll be happy to do what I can to help from there. Good luck!
Thanks @brian_bee I fixed it. Please check another post I did because I am stuck at build and packaging lesson
Hi, I cannot seem to get anything in your tutorials to work. Fastlane keeps telling me that i don’t know my own password. I am on Part 2: Episode 13.
I am running fastlane match nuke development
And then it’s asking me to sign into my github, which I am doing. Then the response says …
[!] The request could not be completed because:
Invalid username and password combination. Used 'madeofmoney' as the username.
I’ve manually logged out and logged back into github 10 times with the same credentials. Please help.
Sorry to hear that.
I can’t tell you why the login isn’t working, but one common thing that can cause issues with GitHub login is 2 factor authentication, so you might check your GitHub account settings. If that doesn’t help, you might next running the commands that aren’t working using the verbose tag.
More generally: The most important thing is to make sure you understand exactly which step is failing and which component(s) are involved: Are you positive this message is coming from GitHub? (Running the commands with verbose should help you double check this). If so, I’d dig in and explore what’s happening with GitHub – are you able to connect via the command line at all? Can you read only or write as well?
Sorry I can’t be more specific from a distance. The good news(!) here is that these are exactly the kinds of blockers you’ll encounter with automation tools in production situations. I know it can feel horrible when seemingly straightforward tutorial steps don’t “just work”, but isolating and resolving this issue can be a learning experience in itself. Good luck!