Log a warning or fail the build on mismatched Unity versions

[vex-ll]

Context

It is possible to set a unityVersion or a customImage from a version that's different from the version in the project being built. This could result in unexpected behavior from the differences of unity version -- in my case, the project was in 2022.3.x and I incorrectly set the a unityVersion (for Mac) and a customImage (for Windows) on Unity 2023.2.x, resulting in fonts rendering incorrectly or not at all.

Suggested solution

Whenever the unityVersion or customImage is set, the execution should first read the first line of the ProjectSettings/ProjectVersion.txt file to validate that the versions match. If not, the build should either issue a warning or outright fail.

Considered alternatives

Using the auto value for unityVersion is an alternative, but might not be desirable or possible every time, especially if you need a custom image for builds.

Another alternative is the project manually checking from bash the contents of the ProjectVersion.txt file, but it would be of course much nicer if this happens out of the box from unity-builder.

[GabLeRoux]

Thanks for reporting that! A warning is a great approach to help identify this issue without disrupting the build.

Failing the build is also an option, but since it could be a breaking change, I think a warning would be a better initial choice.

At some point, we could introduce a strict parameter to fail builds on warning. We’d probably need to discuss this a bit more, but I’m sure we can go forward with a warning. 👍 thanks again!

[webbertakken]

Agree with the warning.

A few more thoughts:

Since under normal circumstances the unityVersion shouldn't be specified at all, as it autodetects the version from the checked out project, I'd say our stance should be that the correct way is to not specify it at all. I think the docs currently reflect this.

For a custom image, you'd expect someone to use the version of their actual project under normal circumstances. But upgrading a project and CI step by step might be a legit use case where you wouldn't want the pipeline to artificially fail.

Therefor I would suggest sticking with the warning for this issue.