a 500 is an internal server error, which

[fading wave]

I would recommend to wait a half hour and try again, uploading a build is incremental, so it should be faster every time.

There's not much I can do about the 500, I could try reporting it to the team if I had some more information about the project, but it will not be fixed for a while. If you want to help us out, it could help to DM me the error you get in the DW (or error console, the callstack) as well as your project ID and environment ID.

This information may help narrow down the specific call that failed in the mutiplay server

[meager quest]

The only difference between the build that failed with internal 500 error and the one that uploaded successfully was the fact that i made a script to auto delete BurstDebugInformation_DoNotShip and BackUpThisFolder_ButDontShipItWithYourGame folders because the build was 1,85 GB, then it became 150 MB and it worked

The cancelled exception happened when i tried to upload a build without an already uploaded build, it created the build on dashboard but did not complete the operation, in fact on dashboard it was on "draft", maybe because the build was to big as it was the 1,84 GB one

I have just tried to redo everything with a normal size build without the BurstDebugInformation_DoNotShip and BackUpThisFolder_ButDontShipItWithYourGame folders and everything worked fine, so do you have any suggestion about how to manage those two folders instead of deleted them right after the build by custom script? Because deploying from the the editor cause the editor to compile the build not only upload the build

[fading wave]

I gotta go to lunch, but you can just upload a build with the rightclick menu, would that help? Ill come back and take the time to properly understand your pb

[meager quest]

no that is not my problem, please take your time to read all and let me know if you understand, thank you

[fading wave]

Ok, so there's a few parts to this answer...
I already got a request from a user to support "Ignore" paths. The user is also using a post build script to eliminate artefacts that should not be uploaded.
I think we'd augment the build section of the gsh file to support that, that way you dont need a custom script.

That said, I think relatively large builds are probably supported, tho I dont know off the top of my head. I think most likely its that we time out waiting for the build to be ready. If you were to retry (because the upload is incremental), it should probably succeed... However, I recognize that's not a satisfactory answer, we probably additionally need to set up a configurable timeout waiting for the build to be ready.

We have the inclusiong of "ignore" paths in the backlog, tho we havent yet planned it.

We also have planned to make a lot of the api surface available for you to consume, so you can customize the process and include callbacks.

At the moment, the raw deployment API remains public and you can use it to inject yourself in the process, though it wasnt entirely designed for that, so its not as clean as I would like.

Details here.

In a nutshell, after the build binaries have been generated, the PropertyChanged in the buildItem will fire, with Status changing to new DeploymentStatus("Successfully Built Binaries", messageSeverity: SeverityLevel.Info)

If you listen on that event, you can do something like move/delete the item.

var buildItem = GetBuildItem(); //see post above
buildItem.PropertyChanged += (item, event) => 
  { 
     if (e.PropertyName == Status && ((IDeploymentItem)item).Status.Message ==  "Successfully Built Binaries" )
         CleanOutput();
 };

I fully recognize it is not a satisfactory answer, but you do have the flexibility to control a lot of the process, and I want to give a thorough answer. We'll look into ignore paths