New experimental method to avoid duplicate editor workflows

[AndrewKahr]

We have a major issue of duplicate workflows and more complicated logic as Unity continues to add/remove modules for different versions of the Editor. To fix this, the versioning-backend will send supported modules as one of the client_payload fields with a comma-separated list of all supported modules for a specific unity version. Each workflow file then filters their matrix strategy of supported platforms against the provided supported modules field to determine if a module should be built, otherwise it is skipped. This has the benefit of keeping the backend mostly static, save for adjusting the incompatibility filter when necessary if we decide to not support a module, when updating which module types are built in the workflow files. This also removes the need for a new workflow file every time a module gets added/removed. The workflows can continue to be dispatched with workflow_dispatch and it remains clear which modules are built on each platform. See game-ci/versioning-backend#39 for details of the backend changes.

Requires game-ci/versioning-backend#39

Changes

• Remove duplicate workflow builds
• Add workflow dispatch to Linux build workflow

Checklist

• [x] Read the contribution guide and accept the code of conduct
• [x] Readme (updated or not needed)

[github-actions[bot]]

[webbertakken]

I agree that ultimately this would be the way to go (given some changes, reducing complexity and with well defined separation of responsibility and forks should keep being able to use the workflows as standalone using workflow_dispatch)

Unfortunately I currently do not have capacity to debug more large changes to our build flow. As introducing and synchronising workflow changes between this repository and versioning backend usually requires a good amount of debugging, which happens to be very tedious work while on the clock of the scheduler which runs every 15 minutes.

We also need to first stabilise builds that are currently failing https://game.ci/docs/docker/versions. v0.15 was the last version where all builds were working as expected.

In the meantime, a simpler way to achieve this would be to follow the existing approach for differentiating between target platforms for different versions (i.e. legacy, post_x, post_y,post_z`) and simply have another workflow describes which target platforms to use for that version.

Note that you can diff between the workflows in WebStorm using Compare with clipboard, and you'll see that there are only 2 lines different, which make the complexity very manageable currently.