Feasability of UCB integration?

[fadookie]

Hello,
I am interested in deploying a static analysis tool. I am looking for something that ideally would run entirely on the Unity Cloud Build stack, and that I could even configure to fail my build if the quality checks don't pass. How feasible do you think that would be, or if it won't be possible with this tool, perhaps you know of another one?

I saw your unite talk and you mentioned integration is possible with Azure but I don't really want to have to set up a secondary CI server and I'm not sure if it would be possible to make such a setup fail the build.

It's challenging because I think it would have to be able to be executed from within the C# editor environment on UCB. Unity has mentioned they are hoping to add roslyn support in the future but so far I don't see information that this has happened - but maybe if they do this would become possible?

It's possible to specify a custom test method and I think from there you may even be able to call external programs, so maybe if I bundled roslyn I could call out to the command line version of this tool?

Thanks.

[vad710]

Hi @fadookie,
Just to make sure I understand what you're looking for - you'd like to be able to run the analyzers on the UCB servers without relying on an external server?

I know that with UCB, you can setup hooks to external systems. Not sure if you can get it to launch something on their servers.

Perhaps there's a way to modify the unity compiler to reference some external tools, check out mcs.rp and csc.rp in these docs: https://docs.unity3d.com/Manual/PlatformDependentCompilation.html

Also - you could also reach out to Unity and ask them to integrate the Analyzers into UCB ;)

[fadookie]

@vad710 yes. Basically I just would like to run lint/static analysis as part of my UCB job. You can specify a custom C# method as your "test runner" - by default it calls UnityTest.Batch.RunUnitTests but I think it would be possible to override this with a custom method that calls an external process to run the analyzer. But for this to work, might need to bundle a roslyn executable in the git repo - I'm not sure if the UCB job has the correct privileges to do this but I can try.

Regarding the mcs.rp - that's cool, I didn't know about that. But it looks like you can only pass arguments to the mcs (integrated mono C#) compiler with that method. So I don't know if that would help here unless there's a way to integrate this or another analyzer into MCS compile step.

And I have made feature requests almost 2 years ago now to Unity/UCB team for some similar features like coverage reporting and integration test running... they don't seem to be adding many new features at the moment, but it's worth a shot.

[fadookie]

Also, related to this, have you ever tried to get this to run on mac / mono runtime / roslyn for mac?

I tried running the CLI binary with mono 5.4.1.7 and got this error:

System.AggregateException: One or more errors occurred. ---> System.TypeLoadException: Could not load type of field 'Microsoft.Build.BackEnd.Logging.LoggingService:_loggingQueue' (20) due to: Could not load file or assembly 'System.Threading.Tasks.Dataflow, Version=4.5.24.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. assembly:System.Threading.Tasks.Dataflow, Version=4.5.24.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a type:<unknown type> member:<none>

[vad710]

@fadookie - my guess is that running an executable on the UCB servers is either not technically possible or against their terms - as you could do a lot of harm that way. If it's possible and not against their terms, it's certainly something to try. It's also possible to run the analyzer via C# code as well - this is probably the path of least resistance.

I was working on a dotnet standard version of the binary a little while back (see this fork: https://github.com/vad710/UnityEngineAnalyzer/tree/dotnet-standard ) but at the time, there were a handful of bugs that I kept running into. The last set of bugs I was trying to work around was related to not being able to load a visual studio project only using dotnet standard libs - it could be that this issue was resolved since then.