As you might be aware, 2019.1.3f1 experienced a lot of build failures recently which could be worked around by switching your Unity target version to 2019.1.2f1. Fortunately I can report that I tracked down what I believe to have been the main cause of these issues and iOS build failures should now be back to normal.
This means that you can go back to targeting 2019.1.3f1 if you want, or return to targeting “Always Use Latest 2019.1” versions - which now targets 2019.1.4f1. We have recently had several unexpected breakages from releasing new Unity versions however. We have a few features coming soon to make it easier to detect and avoid breakages introduced by new Unity versions. We’ll also be making our testing suite for new Unity version releases more extensive and automatic.
If you are still experiencing iOS build issues in 2019.1.4f1 then please feel free to post here or open a support ticket - and if you were previously experiencing issues which went away when switching down to 2019.1.2f1 then it would be good to know if these are now resolved in 2019.1.4f1. Tracking down the replication for this issue was very tricky - although I believe that the majority of new iOS issues should be resolved now, I definitely want to keep a close eye on things and make sure that this has worked for all of our customers.
It would be nice to have a quick way to see what latest version of Unity will be used in a build, e.g. I just verified in the dashboard that my Latest 2019.1x build will indeed use 2019.1.4 by clicking the Edit button on a config and pulling up the version popup. I don’t know of any easier way to do that (except just starting a build and seeing what shows up in the log).
Yep, that’s one of the major things we’re currently looking at adding to help users determine what’s going on with the “always use latest” versions. We’re also looking at an alternative config option which would attempt to lock your Unity version to always use the exact same version you are running locally.
In the long term things should just go back to normal where we very rarely experience breakages due to minor/point releases. As you might be aware though Unity is currently going through a large set of major refactors in several areas. Mostly this is being done to improve stability and performance in the long term but it’s been generating a few short term issues recently as things shift over.
Thanks for the quick reply! My use case typically is I want to start a build as soon as I know there’s a new Latest on UCB, maybe even before I update locally so I know beforehand if there are any issues.
I’m currently looking into a few cases where my fix isn’t working the same in production as it did when I was running this in our internal testing environment - I’m hoping that between this fix and the release of 2019.1.4f1 things should still be improved on this front but I may have been too soon to declare that the issues “should be fixed”
Hi there, I was having issues with building for iOS using 2019.1.3f1 but this issue went away when switching back to building with 2019.1.2f1 as suggested in other posts.
I have now tried building with 2019.1.4f1 but it still won’t build correctly, 2019.1.2f1 however still builds without any issues. (I am using local version 2019.1.4f1).
19477: ▸ time=“2019-05-31T00:59:10Z” level=fatal msg=“Please provide an auth token with USYM_UPLOAD_AUTH_TOKEN environment variable”
19478: ▸ Command PhaseScriptExecution failed with a nonzero exit code
There was a configuration issue in our production service which interfered with the fix I deployed - I just deployed a hotfix to bypass that code and so far all my test builds are succeeding.
I’m a bit reluctant to call it “fixed” since that backfired on me last time but it’s looking good so far.
Hi, I know that this is out of topic for Cloud Build, but Unity 2019.1.5f1 makes build error (USYM_UPLOAD_AUTH_TOKEN) when I run batchmode for building iOS player. I think the issue is related to this thread. Any ideas?
@Kichang-Kim (EDIT: deleted my bad advice, see fatswallow_bside for the correct answer.) That said, if you could report this bug along with detailed replication steps through the editor (Help → Report a Bug) then that would be a great help for identifying why this is happening and resolving it once and for all. I have already mentioned this issue to the Game Performance Reporting team but having more reliable and detailed replication steps is always useful for fixing strange bugs like these.
@fatswallowBesides are you also experiencing this issue locally when running in batchmode, or is it happening in UCB?
I’m running it in Batchmode, and I just resolved it by giving -username and -password option on command line. It looks like “Unity not installed by Unity Hub” is somehow failing to fetch userid/password, thus USYM_UPLOAD_AUTH_TOKEN value is not provided.
Yeah sorry, that’s the correct advice and it should work just fine - ignore what I said! The confusing part (which is presumably an editor bug) is that USYM_UPLOAD_AUTH_TOKEN is expected for iOS builds even when you are not using Game Performance Reporting. But yes using the -username and -password options is the correct way to resolve it.
Hi,
I’m having this exact issue but I’m not using Unity Cloud Build.
I have a username and password in the command line and that’s not fixing the issue on Unity 2019.1.3f1, would you have a fastlane (that’s what we use in our CI) fix or other clues as to why it’s not working ?
I saw in other threads people talking about the CrashReporting being a possible cause for this ? If that issue come from Unity Services we will be forced to disable it on all our projects until it’s fixed.
Also tested on 2019.1.5f1 and it’s not working either.
It seems like it’s not coming from the CI or fastlane but really from some env variable that should have been set.
Any help on this issue would be life saving, thanks!
My bad advice which I deleted was to define the env variable USYM_UPLOAD_AUTH_TOKEN to be an arbitrary string. Switching to an arbitrary string will of course break crash reporting but it should allow builds to go through successfully. Unfortunately I can’t be much more help than that, the username and password is the correct approach for customer use and should be working - reporting a bug is your best bet for getting this resolved properly.