game-ci / cli Goto Github PK

Bug description

I'm currently using game-ci/unity-builder and game-ci/unity-test-runner to build and test a Unity 2021.3.9f1 project.

I've setup two jobs for this:

• test: https://github.com/BoundfoxStudios/community-project/blob/develop/.github/workflows/build.yml#L46
• build: https://github.com/BoundfoxStudios/community-project/blob/develop/.github/workflows/build.yml#L111

As you can see in the workflow definition, both jobs run on Linux, Windows and - for build only - macOS.

Building works reliably on all three operating systems any time.

Testing however has some issues. It works on Linux, but on windows it silently fails (see game-ci/unity-builder#325) due to a license activation error:

LICENSE SYSTEM [2022920 4:19:25] Machine binding 1 mismatch: (value of current machine) 00430-00000-00000-AA128 != 576562626572264761624c65526f7578 (value in license file). Reason might be there is a hardware change on this machine after the license was activated

For example see here or here.

I've noticed that all windows runs (tests and build) use the exact same image:

Digest: sha256:365aa88c7335177e5d7b5e4c911a9dae0b58c0092ef622c057c79e78e6512567
Status: Downloaded newer image for unityci/editor:windows-2021.3.9f1-windows-il2cpp-1

@GabLeRoux pointed out two scripts that are currently used for license activation:

• test-runner: https://github.com/game-ci/unity-test-runner/blob/main/dist/steps/activate.ps1
• builder: https://github.com/game-ci/unity-builder/blob/main/dist/platforms/windows/activate.ps1

He also pointed out, that the ubuntu base images use a hardcoded machine id (https://github.com/game-ci/docker/blob/main/images/ubuntu/base/Dockerfile#L68) whereas the windows machine do not (https://github.com/game-ci/docker/blob/main/images/windows/base/Dockerfile).

@webbertakken pointed out that windows should take the serial out of the license file and activate it (not being sure if that is affected by the machine id):

https://github.com/game-ci/unity-builder/blob/579daa93a634c0d09499e5f907f2b42b4ff70fdb/src/model/build-parameters.ts#L87

For me, it seems that due to a difference in activating the license for test-runner and builder on windows, it can fail on the test-runner. I've never had a successful run so far. :)

I've also seen that any test-runner run fails activating with the same wrong machine id, it's always 00430-00000-00000-AA128.

Expected behavior

Test-Runner and Builder works on all operating systems.

A first step after creating the CLI is to make a simple build work from a local machine.

We'll go and add back features after that.

Context

Currently, the logs coming from v2.0-alpha versions of the action are borderline unreadable -- there's just too much information. This makes it very difficult to trace down build errors.

Suggested solution

GHA supports line grouping: https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#grouping-log-lines

Instead of printing 7000 unseparated lines, they could be separated into logical groups, perhaps one for each step of the process. That way you can more easily inspect different sections of the log.

Considered alternatives

Additional details

Context

My team has a situation where we can’t run playtests because of asmdef’s in Unity not working with our project flow, but instead found a way to validate things in-game by running a scene from the command line (scene is started from a static method). We want to start the scene to run the tests before a build, but you can't enter playmode from a static method in -batchmode if -quit is also present.

A configuration option that allows removing -quit from the Unity command line parameters would solve our issue (although it means we need to handle the exiting of the editor ourselves with EditorApplication.Exit(0))

Suggested solution

Add a config like

quit

Bool whether the editor should quit after building
Note: If quit is disabled, your build method must handle exiting Unity with EditorApplication.Exit(0) on its own
required: false default: true

Considered alternatives

Forking the builder and monkey patching it

Additional details

We can't call /opt/unity/Editor/Unity ourselves since it's gone when you leave the build step. It would also mean we have to redo the licensing/etc

The following is some bash code that can handle the optionally passing -quit, although I don't have an equivalent for the Powershell build.ps1

#!/usr/bin/env bash

function printparams() {
  echo "$@"
  echo "$#"
}

quit=""

printparams \
  ${quit} \
  -two

quit="-quit"

printparams \
  ${quit} \
  -two

Bug description

When the return_license.sh step is called, when using Unity 2019, the library is reimported as the command line script opens up Unity, with the last open project, but switches platform target to Linux Standalone. This wastes upwards of 10 minutes on projects waiting for this step to complete before being able to deal with the final binary.

How to reproduce

Build a project using Unity 2019 for Android, and observe the return license step

• Expected behavior

Unity does not reopen a project and cause the library to be reimported.

Context
Introduce a simple plugins system in the CLI that can be extended.

Plugins themselves are centrally maintained (as part of the CLI itself?).

Rationale

Currently if someone wants SonarQube to run, they have to spend several hours or days to implement it properly.

Each team is doing this separately, which is bascially a waste of everyones time and in practice it means that new developers will not have cool tools like this integrated.

Using centrally maintained plugins allows the community to together come up with the best approaches for each plugin.

Technical details

The interface of an action could look something like this:

- uses: unity-builder
  with:
    plugins:
      sonar: { my, config, params } # specific to sonar

A plugin definition, maintained by the community could look something like this

class BlenderAddOn {
  static get name() {
    return 'blender';
  }

  static get version() {
    return '1'
  }

  static get dockerCacheKey() {
    return `${BlenderAddOn.name}.${BlenderAddOn.version}`
  }

  static getAptGetPackages() {
    'my-package my-other-package'
  }

  static getRawDockerInstructions() {
    return `
      RUN echo 'test'
      RUN echo 'another layer'
    `
  }

  static runBefore() {
    if (someOS) {
      // install blender on VM instead of in docker
    }
  }

  static runAfter() {
    // cleanup
  }
}

It's not just an extension of the Dockerfile, but also other logic: a plugin is something that goes into a registry. And each part of the logic asks the registry if there is a piece to be injected in the logic that it is responsible for.

For example:

• Docker build (docker.ts) will use getAptGetPackages and inject it into docker as an argument. It'll do this for all active plugins.
• After it detects that your repository is dirty or not for example, some code, probably in pre-flight.ts or something, would call runBefore

Since the CLI must be able to run builds, tests, and perhaps more, a Jobs system that selects a job based on the command that was passed should be introduced to keep things sane.

for example: gameci build . should run the build job.

After #4 and #9 are finished, we'll make a plugin for installing and running SonarQube.

Please add any requirements you might have of that plugin here.

The CLI should be able to determine what it's host machine is capable of.

Based on the host's capabilities subsequent configurations can be determined.

An example: On a windows runner, when running a windows-il2cpp build, we'll need to use different images and parameters than when running a linux-il2cpp build on an ubuntu runner. Both of these use docker, but for mac we run directly on the machine which again behaves differently.

The goal of this issue is to have a proper mechanism to determine strategy based on

• user input
• host capabilities
• configuration

I find out that https://license.unity3d.com/manual is unstable to activate and I can not build a CI for a lot of days.So i just want to know whether this repo is working?

Right now we only process Unity projects, however we have the ambition to support any other game engine as well, as long as they support open source tooling.

The goal of this issue is to make a thin abstraction / strategy layer that takes care of a few things:

• Detect the projects Game Engine
• Fire Game Engine specific jobs
• Separate between game engine specific and non-specific logic

We'd like to create a CLI so that the action can use it instead of having its own logic.

Later this CLI would move to its own repository.

The CLI can later be used from all CI environments as well as locally.

Scope:

• Includes general architecture
• Does not include any builder functionality

AC:

• Being able to work locally, so that we can start adding functionality.

After #4 and #9 are finished, we'll make a plugin for installing Blender.

Please add any requirements you might have of that plugin here.