In general you have two solutions for 2FA with iTunes Connect TestFlight:
Create a CI/bot/“machine” user on iTunes Connect which does not have 2FA enabled, and will only be used for automations, e.g. to use it on bitrise.io. This is probably the easiest solution, as once you create the user it’ll just work, no future changes are required. Simply just register a new iTunes Connect account, just like a regular account, the way you registered your own iTC account, and simply never use it for development / login, only for integrations.
Follow the official instructions (if any) of the tool you use to do the deploy.
In this case specifically / what the reported issue might be
Now, the guide here states that you can run a command locally, and you should provide the output of the command as an environment variable. For environment variables you can use App Env Vars and Secret Env Vars - from the screenshot it seems you used Secret Env Vars. That’s OK, but as you can see in the orange notice Secret Env Vars are not available in pull request builds. This is one thing what might cause the issue for you.
Another thing is, on the screenshot you did set FASTLANE_SESSION as mentioned in the guide, but you should also make sure to turn off the Replace variables in input? option of that env var, so that Bitrise (CLI) won’t treat the $ characters in the value as env var references.
Last but not least, and I’d say in your case this is the most likely cause, you should replace the \n characters in the value printed by fastlane spaceauth, because if you do provide \n there, it will be encoded properly to represent the \and the n characters, while what you can see in the fastlane docs is for bash, where \n means newline. To do this simply replace all the \n with an actual newline (hit enter/return) in the env var value on bitrise.io. That will be the same as if you’d print \n in bash / the way the fastlane docs expose the env var.
I’m running in circles and can’t quite figure out the reason. I read like half a github about it, and in the end i figured out that it is somehow related to the Bitrise and how it interprets the cookie itself rather than a problem with Fastlane
Bitrise does not interpret anything in the env vars, except the $ANOTHER_ENV_VAR references if there’s any and the “expand” option is enabled. Other than that it’s just an env var, like any other.
ok, well thanks for help anyway. this Bitrise CLI will be a big help for me for future anyway (cause pushing always to git repo is quite a pain if i do some changes locally to the pipeline or code).
If i won’t figure out the problem (maybe i screwed up the logging in in spaceauth) then I will ask guys on fastlane what might be the reason.
Sure, and if we can help with anything please let us know!
I’d also advise you to try to generate & set the value again - a quick tip: if you set the value directly in bitrise.yml mode then you don’t have to modify it, \n should remain \n, you only have to replace \n if you input the value on the Web UI / in the Editor. Simply just generate a new value and replace the value in bitrise.yml with the new one basically:
- opts:
is_expand: false
FASTLANE_SESSION: "PASTE THE VALUE HERE"
Setting it through the web ui should work as well of course, but in that case you’ll have to replace the \n chars with actual newlines, which will be serialized as \n when written into YML.
I tried to generate new one and right now I get the message
"Two Factor Authentication for account ‘xxx@xxx.com’ is enabled
Your session cookie has been expired.
Please enter the 6 digit code: "
Which is 100% fastlane related. Though sadly no idea how to solve that one, but now I’m a one step closer.
We just discovered one more edge case when 2FA / the Fastlane Session won’t work: our servers are running in US and it seems that the (fastlane / apple) session is location aware. This means that it might not work if you’re not in the same “region” as where it’s used. It should work if you’re in the US where our runners are, but otherwise if you generate a session on your Mac it might not work on our US build machines.
Did you try the things mentioned before in this thread?
If you did, I’d suggest you to contact the fastlane guys as our step just runs the relevant fastlane tool - you can see the exact command the step runs in the step’s log.