In an effort to standardize how we handle all our target configurations, next week we will be releasing a new feature to bring all build targets into parity when it comes to the output executable name. Currently, only standalone targets like Mac are able to set the executable name via the Cloud Build UI.
The ability to set the executable name has been available for other targets (minus iOS) via the Cloud Build APIs.
By the end of next week, the executable name field will appear under Advanced Settings for all build targets, including iOS. By default, the executable name will be set to the name of the build target until customized.
Previously, all iOS builds were output with build.ipa. The output ipa name will reflect the executable name. If you are using custom build scripts, it is recommended to rely on the UNITY_PLAYER_PATH environment variable instead of hardcoded file names. This environment variable will point to the build output.
Hi,
Iâve started getting an error when the post build script is trying to upload to appstore connect, because the ipa filename changed (donât know how or why), but I donât have the âexecutable file nameâ field in the configuration
Having the same issue. At first, I thought it was giving the target name to the ipa file but even when I change the target name and got a clean build the ipa filename stayed the same.
Same here, the filename changed because of the Unity Cloud build changes they are implementing (current version is â7.2.3.2.4.2â), we added a new parameter in the upload script to manage this but the build name has a whitespace (âiOS Distribution.ipaâ, I suspect this is the name of the certificate we uploaded but I canât verify it right now) and the upload fails.
Our release in production is currently blocked due to this issue.
Thank you for the feedback here and via support tickets. We are tracking the issue a few of you mentioned above and indeed the issue is with blank spaces in the artifact name (for iOS builds). The current workaround, while we resolve this, is to create a new build target with no blank spaces or you can open a support ticket and we can change the build artifact name manually for individual targets.
Removing blank spaces does not work.
We use UNITY_PLAYER_PATH, which previously was:
â/BUILD_PATH/<ORG_ID>.<PROJECT_ID>.ios-master/.build/last/ios-master/build.ipaâ
and now is
â/BUILD_PATH/<ORG_ID>.<PROJECT_ID>.ios-master/.build/last/ios-master/iOSâ
The UI updates should be releasing within the next day to allow for easier customization of the executable name, outside of using the API. In the mean time, we released a patch today that will trim white spaces from executable names.
If there are still issues with the UNITY_PLAYER_PATH please let us know and we will dig into what could be causing this issue.
@ , as of moments after your post this should now be fixed. UNITY_PLAYER_PATH should point to the correct build artifact name (which is likely not going to be build.ipa any longer). If you are still having issues with this please open a Support Ticket and we will take a look at this with you.
You could solve all these questions by simply logging in the cloud build log the actual path should the dev wants to access the build, and it would solve many hours of frustration. you would offload support tickets and bug reports that is an actual feature ( oupsâŚ)
So let me suggests few things:
â the executable name property default value should be 'build" so that you donât upset current working projects that starts failing for no apparent reasonâŚ
â the cloud should detect usage of $WORKSPACE and $TARGET_NAME and other similar keys that are linked to the possibility of wanting to access the produced executable and log a warning in the log saying that you might want to double check on this new feature that -breaks all- previous config trying to access the executable file.
â and .ipa is not an âexecutableâ, so itâs misleading, it should have a proper property with the right label on it.
â putting a warning like you do on many other places in the config form would go a long way in helping us know about this breaking change⌠The Unity cloud is a place where reliability is key for peace of mind during production, breaking change like this is worrying when it could go unnoticed!
Oh, and as I explain the situation to other devs and managers in the team as to what happen, the last suggestion would be to make it optional!!
Itâs really frustrating to witness careless and unnecessary api changes without any consideration of the necessity to make the transition smooth⌠I am all in on making the product and service evolve, but there is a right way and a wrong way to do it thoughâŚ
