Document build process

[thestonefox]

At the moment there is no documentation of how the build process for Malimbe works.

From what I can tell I am able to clone the project, open it in Visual Studio and build the solution which exports to the appropriate solution configuration (default is Debug or Release)

This exports (let's assume the config is on Release) to Malimbe/Sources/UnityPackaging/bin/Release which contains the appropriate Editor and Runtime directory that can be copied into a Malimbe Unity project (e.g. Zinnia, VRTK)

From reading the docs though, it would seem that upon building in fact that UnityPackaging directory should be populated with the latest build changes.

Furthermore, how do official builds get created? Is this an automated process once a pull request is merged into the develop branch?

Does it:

• automatically build the solution and put the output in that UnityPackaging directory
• bump the version number (what is the logic if this is automated?)
• auto generate the changelog
• auto publish the release package on GitHub

Or do the above require any manual steps? If so, what are they?

[thestonefox]

Perhaps using the GitHub Wiki would actually be useful for additional Malimbe Documentation?

[bddckr]

Documentation is needed, of course.

---

From reading the docs though, it would seem that upon building in fact that UnityPackaging directory should be populated with the latest build changes.

It is. Exactly what you mentioned - the Editor and Runtime folders in the build output folder are used. This is the default for any MSBuild project and any .NET developer would be familiar with it. The additional .meta files seen there are more of a build artifact to enable CI builds. This should be improved to include the proper files in non-CI builds, too (i.e. the Readme etc.)

Furthermore, how do official builds get created? Is this an automated process once a pull request is merged into the develop branch?

Does it:

• automatically build the solution and put the output in that UnityPackaging directory
• bump the version number (what is the logic if this is automated?)
• auto generate the changelog
• auto publish the release package on GitHub

Or do the above require any manual steps? If so, what are they?

CI+CD is automated with Azure: The Malimbe pipeline references our generic templates.

[bddckr]

The flow to work on this repo is the following:

1. Work on feature/fix branches and open a PR against develop. All commits need to be semantic commits and follow the angular commit format. Can look at any existing commit to see that. Merge the PR once it's ready.
2. Whenever a new release should be done merge develop into release and push. The pipeline will
   • Build via the same CI that runs for any commit, that is build and fail if something's wrong
   • Figure out the SemVer version number to use based on the semantic commits
   • Bump the version number to that
   • Append the changes to the changelog
   • Commit those changes
   • Create a release with all of the previous changes included on GitHub and release that using that new version number
   • Create and upload an UPM package to npmjs.org which is usable in Unity via its package manager

[thestonefox]

It is. Exactly what you mentioned - the Editor and Runtime folders in the build output folder are used. This is the default for any MSBuild project and any .NET developer would be familiar with it. The additional .meta files seen there are more of a build artifact to enable CI builds. This should be improved to include the proper files in non-CI builds, too (i.e. the Readme etc.)

From reading the readme: https://github.com/ExtendRealityLtd/Malimbe#unitypackaging

and looking at the files included in the repo:

https://github.com/ExtendRealityLtd/Malimbe/tree/develop/Sources/UnityPackaging

it seemed to me like I expected the Package folder to be updated with the new compiled DLLs.

So we're saying that when you build Malimbe instead you actually get

/UnityPackaging/Release (or Debug depending on the config selected)

And you can use that for testing.... but don't commit it, and the build process (merging develop to release) is the thing that actually creates the updated /UnityPackaging/Package directory?

[bddckr]

You put (re)sources you need to be part of built packages into Sources/UnityPackaging.

The actual built package will be in the build output folder of that UnityPackaging project. I'm just (ab)using the project build ability to do some file copy n pasting to "build" a package.

The CI+CD pipeline takes care of kicking of a solution-wide build, which does the necessary file-copying from other projects' output folders into the UnityPackaging's output folder. The CD steps then make sure to create the UPM package and kick off all that semantic release stuff.