Hi All,
I wanted to start a new thread on Feature Requests now that we have launched Build Automation. So please use this thread to ask for specific features, improvements, and requests.
The team and I will be looking at this thread (and the forum at large) actively but I will be locking the old feature request thread since that has been around for years and many of the requests in there have been resolved.
Not sure this would counted as feature. But I want the build system changed to be git on virtual disk
I have tried to inquire the problem in this post > Zip cache library take too long and that take up build time
To be summarized I just want the system to rework for these problems
1 - The need to zipping and loading Library folder. For the large project this process waste too much time
2 - The system also need to pull whole project from repo for each run, which also waste too much time and resource. Especially when internet to our repo server are not great
3 - Rerunning just need to do this whole process again
All these burn too much build minute over the build process itself
The solution I can think of is, if we use git repo as project source, unity should store both library folder and project repo together like the actual project in our machine. And put those all in virtual disk that can be mounted/unmounted on the server
Also project should be stored as git repo (just shallow clone would be enough?). So it could be pulled to update more efficiently
Since the library folder most likely larger than project itself so it has not much point to store library folder but not the project
With this system I propose, the rerunning also would be a lot faster
ps. I don’t think my request in the old thread has been resolved as of yet, hasn’t it?
An improvement of build speeds are the number one requested feature from our users. We are actively looking at ways to solve this problem. The solution you propose is one of many that we are investigating. We are analyzing timing data to determine which portions of the build process are the slowest. From this data we are determining what solutions we can implement that would improve the speed of these various processes. For example, if the majority of time is spent importing assets and building the player, that would be an area we might target improvements on before we hit on things like caching.
To confirm, we are looking at longer term persistent “block” storage instead of using Library/Workspace (object storage) caching on a per target basis. We don’t have a timeline on when this would be implemented, or if it provides the speed benefit we want.
I’d love to have the ability to test post-build deployment scripts without having to kick a full build of the Unity project.
+1
More than that I wish I could just rerun the script. I have write script to publish my app to store. Sometimes it just error from network problem and I need to rerun the whole build is not convenient at all
BUT this is the thing I have requested in that old post, since 2020
Unity Cloud Build Feature Requests page-2#post-6323898
@Thania we are investigating adding logic to those steps such as retries on failure.
@mike6502 I’m not sure we will be able to make a way to test post-build deployment scripts without having to launch a new build, but if we get the step logic separated out into discrete steps which can be re-ran independently that might help you with the problem you’re having. I’ll think on it some more and see what we can do to help. Are you specifically interested in testing the code that you supply? can this be done locally? or are you more interested in testing if the code you supply working in the build environment? I do plan on being way more transparent about the execution environment and what’s installed/available on the build machines etc, so again that might help you out.
Thanks @wrossmck-unity , yes, I’m interested in validating and fixing my own deployment scripts in the build environment. I definitely test scripts locally, using as best-as-I-can simulation of the build environment. But this does not guarantee that everything will work in the real pipeline. For example, I’m on a Mac and cannot test cygwin. Another example: I had a script fail on a windows builder because it couldn’t find npm. Another: I had a typo in an environment variable, and there was no way to know until the build finished and I could inspect the log files. etc.
Most of the time the fix steps are 1) figure out why the server is different than local (paths, missing tool, etc) by checking build logs and forums/blogs, 2) make trivial changes to the deployment scripts, commit/push/merge and try again. When the billing was flat rate, this was inconvenient. Now with metered billing, this is costly.
More transparency about the build machines and environment would be very helpful.
I should also note that my deployments might be pretty common for mobile developers:
@mike6502 Appreciate the response and the details! I think I understand what might help here. We have an idea to run arbitrary scripts in the same execution environment that builds run in, which should enable much faster turn around that waiting for a build to complete first. might not give you 100% confidence but should decrease the iteration time (and cost!) significantly. Something similar to this is being worked on today and might be public facing around summer (sadly cannot promise this though!).
Totally agree on adding dedicated support for common deployment targets such as the ones you listed and steam, itch.io, etc. It’s definitely on the list of things we want to invest in, although not actively being worked on today. We’re currently doing our initial planning for next year, so I’ll bring this to the team and see what we can do.
Configure a maximum number of builds to keep for each Build target configuration.
For example I want to keep the 50 last releases but only the 5 last nightly and commit builds. Currently we don’t use our nightly or commit builds because we don’t want to have a lot of builds to clean manually and we want to keep our storage cost as small as possible.
Allow to use CLI tools from Steam and the Meta Quest store so we can use them in a post-build script to publish automatically to a branch any successful build
To do a proper continuous integration you need to be able to deploy your build somewhere automatically and now publishing still requires us to download the apk and to use the command line on our computer to upload it
@Myron yes absolutely agree on the build retention settings to help manage storage. it’s on the list. We want to do number of builds per config as well as an overall sum of GB (maybe useful per project/org) too. For now this is only achievable via the API, only works based on time/date instead of number of builds, and is not branch/config aware - so it applies to all builds across the whole project. we will improve this later.
Do a POST request to /api/v1/orgs/{ORG_ID}/projects/{PROJECT_ID}/artifacts/delete/?allWithExclusions=true
with a body of:
{
"excludedBuilds": [],
"filters": {},
"deleteOnOrBeforeDate": "2018-10-01T18:51:33.412Z"
}
Also completely agree on the stores deployment topic. I’ll add the meta quest store to our list for integrations
I need a way to sign a Windows build. Not sure that exists currently. Documentation exists for macOS in the manual, but not Windows.
Would really love to see a supported (automated) way of pushing builds to pretty common external locations such as S3 post build
I’d like to see a unique build machine/container ID of some sort in a build overview. We sometimes get 2-3 spurious failures in a row(i.e. failed to download a stock Unity package, locked file when building addressables, etc.) and it’d be useful to know if it’s the same build machine/container each time. Would also be useful for build timing to see whether consecutive non-clean runs are actually running in the same environment or not.
Would you support officially UnityCloudBuild Manifest.json file at “Assets/UnityCloud/Resources”?
With old Unity Cloud Build, JSON file named “UnityCloudBuild.json.txt” is put on “Assets/UnityCloud/Resources”. I used it. I displayed some this file content on my mobile game to show the build version and build number for debug.
This is Japanese document: ビルドマニフェスト - Unity マニュアル
This is Korean document: 매니페스트 빌드 - Unity 매뉴얼
This is Chinese document: 编译清单 - Unity 手册
English document may be deleted.
With new Unity Build Automation, there are no documentation about “UnityCloudBuild.json.txt”.
By the way, I tried to load “Assets/UnityCloud/Resources/UnityCloudBuild.json.txt” with Unity Build Automation, I could get some target information. I think Unity Build Automation seems support “Assets/UnityCloud/Resources/UnityCloudBuild.json.txt”. But I think this is not officially.
Would you support officially UnityCloudBuild Manifest.json file at “Assets/UnityCloud/Resources”? And would you document it like old Unity Cloud Build?
In our application we need to know the build number and branch (so we can determine release track for our app, cos we have built an auto updater system) so we hacked it to save UCB_BUILD_NUMBER (and other build time env vars to a file in streaming assets which we then load and query at runtime to know the exact build we’re running… but that feels like a hack. I’d wondered if if would be better for unity to automatically save build time ENV vars eg things like like “SCM_BRANCH”, “UCB_BUILD_NUMBER”, “BUILD_TARGET”, “PROJECT_ID”, “NUMBER_OF_PROCESSORS” to the build automatically somehow so that they can be queried as env vars at runtime?
@RyotaMurohoshi We have recently moved our documentation to the new site here: Unity Build Automation
Also, we have added docs for Build manifest here as well: Build manifest
@hiepu3d
Thank you for your updating for documents and nice support for Cloud BuildManifest.
Can you add a
Add a summary graph view of a configuration’s build size over N time. Should go under Build History.
This may not be all that useful but it would be informative at a glance to visually see build bloat or the inverse when attempting to reduce size.
Hi,
I would like to request an update to the Japanese translation of the web UI.
There’s “設定” twice in the menu and the one is for “Configuration” and the other one is for “Setting”, which is quite confusing.
How about changing the first one to “ビルド設定” or “ビルド構成”.
I’ve passed this along to our Web team to look into.