I’m working to automate UGS setup workflows for our downstream teams. In this context, I am trying to create the required resources for GSH (Multiplay) like a Build, Build Version, Build Config etc.
Through some trial and error, I understand the correct flow for creating a functional build version with the services APIs is:
- Create GSH Build (in my case Linux with File Upload)
- Create a CCD Entry by path (passing in Build CCD Bucket ID, content size in bytes, MD5 checksum string, requesting signed URL)
- Upload file to signed URL (passing in the MIME type in the Content-Type header)
- Create GSH Build File (passing in the Build ID and path of the created file)
- Create a GSH Build Version (passing in the Build ID and CCD Bucket ID)
Frustratingly, creating the build version fails with an internal server error:
{“status”:500,“title”:“Internal Server Error”,“requestId”:“774ddace-bf5e-4d84-bceb-57b0a3222443”}
If I inspect the GSH dashboard for the build, the uploaded file is visible and marked as “Active”, however creating the Build Version in the web GUI fails with the same error. Removing the file uploaded via script and uploading another valid file in GUI allows me to proceed to creating the version in GUI.
This leads me to believe there is something misconfigured for the build file uploaded via script. I’ve inspected the network traffic when using GUI, and I think I am including all the correct parameters in my script requests. One thing that is not apparent from the API docs is whether there are any requirements for requests when using the signed URL. Another point of confusion is how the MD5 hash string should be formatted - do I use standard UTF-8, or a Base-64 encoded string?
There is obviously something about the attached build file which is invalid or failed, but due to the server error I am not getting any actionable feedback as to how to fix it.
As a general feedback coming from someone who cares about DevOps and automating manual workflows, the Unity Services APIs could use some improvement in terms of handling validation errors, providing feedback on these, and documenting proper use of the APIs. There seems to be a fair bit of important info which is left implicit, so you need to dig through the various Unity packages that integrate to these APIs to understand how to use them correctly.