Move Build Script to a UPM Package

[davidmfinol]

Context

Users currently have to redo a lot of the default Build Script if they want to have a custom buildMethod. We should make it easier for users to add to or modify the build method, while still leveraging the default functionality.

Suggested solution

Remove the buildMethod option, and move the default build script to a UPM package that users could choose to include in their project. If they include the UPM package, they should be able to use an API to easily add to or modify the build process. If they don't include the package, Unity Builder would still work by importing the package during the build action.

Considered alternatives

My initial solution was to provide an example BuildScript.cs that users could copy and modify, but this approach is still not as user-friendly as it should be.

Additional details

This issue came from user feedback: https://discord.com/channels/710946343828455455/710946344264794219/839682505434595370 https://discord.com/channels/710946343828455455/710946344264794219/839765128564178966

[Bradshaw]

Maybe another solution would be to add an option to customise the path to copy UnityBuilderAction from.

https://github.com/game-ci/unity-builder/blob/main/dist/steps/build.sh#L51

So an option like:

- uses: game-ci/unity-builder@v2
  env:
    UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
    UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
    UNITY_SERIAL: ${{ secrets.UNITY_SERIAL }}
  with:
    targetPlatform: WebGL
    buildActionPath: /github/workspace/MyCustomBuildAction/

And then in build.sh:

cp -R $UNITY_BUILD_ACTION_PATH "$UNITY_PROJECT_PATH/Assets/Editor/"

With the necessary plumbing to have /UnityBuilderAction/Assets/Editor/ as a default value and pass it around of course

[webbertakken]

Great suggestion @davidmfinol @sbergen!

Indeed I think it's important to keep our build script as the default behaviour as it's used a lot.

If installing a package inside your project - that provides some hooks for your project specific functionality - does the job, it would be preferable I think.

@Bradshaw about

buildActionPath: /github/workspace/MyCustomBuildAction/

This will work but it brings a few problems:

1. It doesn't solve that a user would still have to copy and distribute that script, which is hard to document.
2. We now make it very easy for the user to use a script that's not part of the repository - which I would consider bad practice.
3. Paths are hard. A big portion of our users that ask support messed up a path. Especially in github actions we try to abstract over the technical details and make it as easy as possible to configure it.

But maybe there's a rationale behind your suggestion that I'm currently not considering?

[Bradshaw]

@webbertakken Just avoiding UPM 🤷‍♂️

If paths are an issue, then maybe it's not a good idea