Workflow Versions

[slxdy]

Featuring automatically-generated versions for workflows.
Each workflow run has its own version which is appended to the title as follows:
[major].[minor].[patch]-ci.[run number] | [Commit title]
For example:
0.6.6-ci.1971 | Cleanup

The version is also automatically passed to the compiler, which sets the versions of the built assemblies and the nuget package.
(Because assembly and file versions only support 4 numbers, the format is [major].[minor].[patch].[run number]).
To achieve this, I also wrote a new system for assembly metadata, which is stored in Directory.Build.props. I also removed the outdated assembly attributes.

The indev version (major, minor and patch) should be stored as a repository variable, named DEVVERSION. An example value is 0.6.6. You can find this setting in Repo > Settings > Secrets and variables > Actions > Variables > Repository variables.

I also changed BuildInfo.Version into a dynamic property that grabs the version from the assembly. This also allows mods to get the accurate version of MelonLoader at runtime and not just compile-time. (Changing the constant field into a property won't break backwards compatibility because constants are never directly referenced.)

To compile a non-prerelease build, you can build the project yourself. The version in Directory.Build.props will be applied.
You can also make a non-prerelease build by running the Build MelonLoader and Build NuGet Package manually (thus not through a push).

Let me know if I should change anything (and I apologize for the trash workflow code :( ).

[slxdy]

To prevent confusion, the workflow run for the commit above failed because the DEVVERSION variable is empty for the this repo, which leads to an invalid version being passed to the compiler. To test, you can add the variable to the repo and manually rerun the checks.

[SamboyCoding]

Because assembly and file versions only support 4 numbers, the format is [major].[minor].[patch].[run number]

Not quite accurate, you can (and we arguably should in this case) have a version suffix, so you could do [major].[minor].[patch]-[branch name].[run number] e.g. 0.6.7-alpha-development.384

[slxdy]

Marking as unready because of run number mismatch for the nuget workflow.

@SamboyCoding
Can we turn both workflows into one? Seems like an unnecessary split.

[slxdy]

Because assembly and file versions only support 4 numbers, the format is [major].[minor].[patch].[run number]

Not quite accurate, you can (and we arguably should in this case) have a version suffix, so you could do [major].[minor].[patch]-[branch name].[run number] e.g. 0.6.7-alpha-development.384

CS7034 - The specified version string '0.6.7-alpha-development.384' does not conform to the required format - major[.minor[.build[.revision]]]

You can only use SemVersion for NuGet packages (which I'm already doing btw), but not for assembly version

[HerpDerpinstine]

@SamboyCoding Can we turn both workflows into one? Seems like an unnecessary split.

If you want to see if you can integrate it into the main script I don't see the harm or an issue with that.
There are other repos that also do the same thing.

[slxdy]

Actually, I already did that + optimized/simplified the workflow. I would just have to push the changes

[slxdy]

I suggest testing the Preload module changes. Can't test it for myself