git version into unity version at build time

we need to build unity from the command line (as part of Azure DevOps). We are using the Dinomite plugin. Suffice it to say, unity is being built from the command line, eh? two things we can do before the build start is stuff an eviron variable or a text file with the version string we want to go into the Unity build. The desired goal is to (somehow!) get that string into the Unity build version, but newbs that we are, we don't know how. Is it a programmatic thing in the unity command line build options? Is there a way to start a bit of scripting as part of the build? Is there a way to get the build to start a bit of script and look at the env variable or the file on disk as part of the build? I just don't know...

thanks in advance!

 

You read environment variables and the command line arguments using standard C# System.Environment stuff: System.Environment.GetEnvironmentVariable() and System.Environment.GetCommandLineArgs()

https://docs.microsoft.com/en-us/dotnet/api/system.environment.getenvironmentvariable?view=net-5.0
https://docs.microsoft.com/en-us/dotnet/api/system.environment.getcommandlineargs?view=net-5.0

 

that WASN'T the question. Want to know to get the string (which we know) into the Unity settings, programmatically, at build time, using the dinomite Azure DevOps plugin or via some other route. let's say we can execute a bit of script as part of the build processs, and it can look at an env variable, how to I set the Unity generated program's version # from script DURING a build?

 

You can hook into the IPreprocessBuildWithReport (or IPreprocessBuild, depending on your version). Here's a method by which you can change the player version in script: https://support.unity.com/hc/en-us/...w-can-I-modify-Project-Settings-via-scripting

 

I do both of the things you're trying to do in my build script. I don't do it exactly as you're doing it, but I think you can fairly easily combine the two things I'm about to say.

First, getting a version number into the built game is simple. I use the following:

Code (CSharp):

1. PlayerSettings.bundleVersion = ApplicationConstants.ApplicationVersion;

In my case, I'm setting the version to a constant I have in a static class in my project, which I update manually with each release, but you can set that bundleVersion to whatever you want. It's the same value that appears in Player settings here:



Getting the git version is a little more effort. There are probably other approaches, but I wanted something fairly decoupled. I have a git post-commit hook, which reads the new commit number and writes it into a file.

Code (CSharp):

1. #!/bin/sh
2. #
3. # Writes the current git version to a version info.
4. # Ensure this is placed into .git/Hooks for it to run.
5.  
6. git rev-parse HEAD > last-git-commit-version.gravia-repo-info

That will create/overwrite a file at the root of my repo, containing the most recent commit version number. In my c# build script, and use it to write to a file I include in my build. But you could read it in and use it in your bundleVersion if you prefer that.

 

I'm not sure you folks are paying close attention. I need to do this at part of a command line build. I know about IPreprocessBuildWithReport, but I can't set PlayerSettings.bundleVersion = xxx, because PlayerSettings is part of the Editor, which isn't available at build time. I know how to get the build version from git. I don't know how to get that value into the build settings in Unity at build time, from a command line! Stay with me, I'm sure I'm not the only one looking for this (probably) easy answer? Put it below!

 

Geez, entitled much? Here, take your damn answer:

You can tell unity to run a static method via command line using -executeMethod ClassName.MethodName or -executeMethod NamespaceName.ClassName.MethodName

Then you can edit the version by changing this static field:
https://docs.unity3d.com/ScriptReference/PlayerSettings-bundleVersion.html

 

Maybe it wasn't your intention, but your reply makes you sound like a jerk. Try not to sound so entitled when you're coming here looking for free help.

Anyway, are you using the -executeMethod option in your command line build? The following is my entire script:

Code (CSharp):

1. "C:\Program Files\Unity\Hub\Editor\2019.4.15f1\Editor\Unity.exe" -quit -batchmode -stackTraceLogType Full -projectPath "C:\Users\Dan\Documents\GitHub\Gravia" -executeMethod GraviaSoftware.Gravia.Code.Build.Editor.CommandLineBuildUtil.BuildWindows

That just calls into a C# method that does all the things I described in my previous post, ultimately calling BuildPipeline.BuildPlayer() to do the full build. This way you can use whatever Editor code you want to do the build.

 

Maybe I am a jerk? What's that have to do with the answer? You're going to not answer me to spite me? And thus not answer everybody else for who the answer is unclear?

I would have THOUGHT that calling a static function would be the equivalent of implementing IPreprocessBuildWithReport. That is, both result in "some" function getting called during build time. And at build time, (this is the important bit), PlayerSettings.bundleVersion isn't available. Doesn't appear I have a workable solution yet. What am I missing, besides that you think I'm a jerk for trying to point out you're missing the point of my question? I GET that point!

 

You're seriously not clear on why acting like a jerk would maybe reduce the willingness of others to help you?

Besides, I did answer you, despite you acting like a jerk. And at this point, I've fully answered the question. What you're trying to do is exactly part of my build process. So, go do the stuff I've said to do so far. It works fine.

I won't be following this thread anymore. If anyone other than @EricHFrazer has any questions on this, feel free to private message me, as I won't get any notifications from this thread moving forward.

 

Look I'm not acting like a jerk on purpose. It clearly states in Unity's docs that PlayerSettings.bundleVersion is only available in the Editor, which isn't available from command line builds. What is my disconnect here? If you want an apology, I apologize. I'm not trying to be a jerk, I just don't understand why I can't get to the point, and seemingly waste an entire two days looking for an answer. I appreciate the help attemps though.

 

every "solution" I've seen out there uses PlayerSettings.bundleVersion from a custom menu "build it yourself" option, which is initiated from the user being in editor mode. I need this to happen from the command line in build mode.

 

I'm not sure why that would be the case, since the Player is built from the Editor, and the Editor is where PlayerSettings is available. The command line

--batchmode

argument still launches the Editor, and therefore I would assume loads assemblies. It would have to in order to call the

--executeMethod

target, which must be inside an Editor folder. This would give it access to the UnityEditor assembly, and presumably the PlayerSettings class.

Have you tried implementing IPreprocessBuildWithReport, and it errors out when accessing PlayerSettings? I'm unclear on what you've tried so far that hasn't worked.

 

OMG I feel mentally challenged. I can't access PlayerSettings.bundleVersion from "the code" (player, builder) at all. It only works from the editor, because PlayerSettings.bundleVersion is part of UnityEditor. So not only can I not write it from the build scripts, I can't READ it from the player scripts. Dead in the water. Seems like I'm going to need to find out where it actually stores the bundle version in the files, crack the file manually, and read/write it in the file in BINARY. I think that's been the problem the whole time. I've been expecting an easy solution, but there isn't one.

to remind you of what my goals are, they are this:
1. Write a version string to Unity's bundleVersion during compile time, from a command line build.
2. During player mode, read the bundle version and display it on the UI.

 

Whatever you write in PlayerSettings.bundleVersion you read from Application.version on builds.

If you cannot write to UnityEditor.PlayerSettings.bundleVersion in a script method called via command line at this point, it's no one's fault other than yourself. Good luck doing anything remotely more complex than that.

 

The confusion came from your use of "build time". "Build time" refers to the time of creating the build, at which you have access to all editor related APIs (including PlayerSettings). When code is running in the built player, it is either "in the build" or "at runtime".

 

Okay... I sorted things out. I disagree with Yazaro on one point, but I'm not standing behind my disagreement 100%, I just tested something observationally, and I'll report what did and didn't work.

When you do a build, for whatever reason, unity allows "editor" to be present, at least when calling an external static function on the command line. I don't know about other routes. I (strongly) suspect if you are not calling an external static function, it doesn't allow UNITY_EDITOR to be defined.

Why do I think that? Because if I write a class that overrides IPreprocessBuildWithReport, and then try to build from the command line, the build fails with the amazing report "Failed to build player." Super descriptive, Unity, thanks.

Now when I switch it to -executeMethod BuildScriptExtern.SetBundleVersionNumber (my function), the exact same code works great.

The last trick that fixed this was referencing Application.version at runtime instead of PlayerSettings.bundleVersion.

Here's the solution:

1. from the command line, you must use -executeMethod and call a public static method you define
2. in your public static method, rest assured, UNITY_EDITOR is defined.
3. Don't try and use IPreprocessBuildWithReport and try and build from the command line
4. Use Application.version during runtime. This is obviously read-only
5. pass in whatever environment variables you want to the public static method you define.

And with that, I'm done! Happy Thanksgiving, all! I've officially solved this problem by the end of day and now I can rest up tomorrow w/ aplomb. (never used that word in a sentence before).