Unity an error occurred while resolving packages project has invalid dependencies

Hi, when i write mymac@Username-iMac ~ % xattr -r -d com.apple.quarantine </Users/MyMac/Desktop/MyGame/Packages/packages-lock.json> in terminal it gives this error:

zsh: parse error near `n’

mymac@Username-iMac ~ % is written default when i open terminal then i write your code xattr -r -d com.apple.quarantine </Users/MyMac/Desktop/MyGame/Packages/packages-lock.json>

I open my game folder > packages folder and copied path for /packages-lock.json

Am i doing something wrong?

xebuddha

Offline

Joined:
September 14, 2020

Posts:
27

I have exactly the same problem with 2020.3.2 editor in Mac Big Sur

xebuddha

Offline

Joined:
September 14, 2020

Posts:
27

Bug description

I use the test-runner action configured as:

      - uses: game-ci/[email protected]
        env:
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
          UNITY_SERIAL: ${{ secrets.UNITY_SERIAL }}
        with:
          projectPath: CoreService.Client.Services.Unity
          unityVersion: 2018.4.9f1

The Unity command in activate.sh throws the following error:

An error occurred while resolving packages:
  Package [email protected]:/github/workspace/Packages/CoreService.Client.Analytics.Package has invalid dependencies:
    com.scopely.sdk.core: Package [[email protected]] cannot be found
  Package [email protected]:/github/workspace/Packages/CoreService.Client.Services.Package has invalid dependencies:
    com.scopely.coreservice.common: Package [[email protected]] cannot be found
  Package [email protected]:/github/workspace/Packages/CoreService.Client.Services.AssetBundlePublisher.Package has invalid dependencies:
    com.scopely.jsondotnet: Package [[email protected]] cannot be found

How to reproduce

Configure a test-runner action with projectPath argument.

Expected behavior

The license activation step should run without errors.

Additional details

I tried to run the same command in my local machine and I get the same error:

/Applications/Unity/Hub/Editor/2018.4.9f1/Unity.app/Contents/MacOS/Unity -batchmode -nographics -logFile /dev/stdout -quit -serial SC-****-****-****-****-**** -username ******** -password ******** $HOME/tmp/workspace

I need to add the projectPath argument to make it work:

/Applications/Unity/Hub/Editor/2018.4.9f1/Unity.app/Contents/MacOS/Unity -batchmode -nographics -logFile /dev/stdout -quit -serial SC-****-****-****-****-**** -username ******** -password ******** -projectPath $HOME/tmp/workspace/CoreService.Client.Services.Unity $HOME/tmp/workspace

Also reproduced in the last unity-test-runner version

A few things to try:

• Could you try quoting the project path?
• Does the specified unityVersion match your projects Unity version?
• Is the root of your project inside that folder and is that folder in the root of your repository?

The problem may also be that these packages indeed can not be resolved from the container.

The problem must be more specific than projectPath being broken, as it works with project path in this test-runner repos own workflow and for other projects.

Could you try quoting the project path?

I just tried it. Same error in package resolution

Does the specified unityVersion match your projects Unity version?

Yes, my project’s Unity version is 2018.4.9f1.

Is the root of your project inside that folder and is that folder in the root of your repository?

In the root of my repo I have 2 directories:

• Packages: containing several Unity packages source code
• CoreService.Client.Services.Unity: containing the Unity project that references the previous packages

The problem may also be that these packages indeed can not be resolved from the container.

I just embedded the unity-test-runner repo content in my repo’s .github/actions/unity-test-runner directory, applied the fix in PR game-ci/unity-test-runner#107 and the packages were resolved correctly and the tests were run without problems using this configuration:

      - uses: ./.github/actions/unity-test-runner/
        env:
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
          UNITY_SERIAL: ${{ secrets.UNITY_SERIAL }}
        with:
          projectPath: CoreService.Client.Services.Unity
          unityVersion: 2018.4.9f1

The strange part I find is that somehow it’s picking up the repository root as a project (since projectPath is not specified).

We may need to set the licensing part to a non-existing folder instead.

Oh, I see. Let me know if I can help

We could try out if setting the project path for the activation and return-license steps to an arbitrary non-existent folder solves the problem.

We should also check whether it creates a new project when doing that, and how long that takes. If it indeed ends up creating a new project in that arbitrary folder, we might also consider not passing project path but changing the current directory to something that does not contain a unity project. We could maybe simply create and delete a folder to use as current directory for these steps.

It would look quite similar to the PR you already created before I think, just a different functional implementation.

I did some tests on my project. As you said, when passing the unity project directory as projectPath, Unity tries to resolve and register my project dependencies, which doesn’t seem appropriate. It also takes more time: 111 seconds in my tests.

Passing a non-existent or an existent empty directory as projectPath doesn’t work either. In both cases Unity throws the following error:

Couldn't set project path to: /github/workspace/github/workspace/activate-license

However, changing the current directory to an empty one worked fine. I see in the logs that the Package Manager is trying to resolve packages anyway, but it just does that for unity packages and not for my private packages. It’s also quicker: 43 seconds in my tests.

Great research. Nice effort!

changing the current directory to an empty one worked fine.

I think this should be the right solution for builder and test-runner then;

Before:
- Creating a folder that nobody possibly has in their project, 

Activation step:
- Changing directory there, 
- Run activation step
- Changing directory back to default

Run project based steps:
- Run project based steps (build in this case)

Return license step:
- Change directory again to the same one as before
- Return license
- Change directory back to default

After:
- Removing that directory

I see in the logs that the Package Manager is trying to resolve packages anyway

Yes, I believe it creates an empty project with the default dependencies. (this is why return license should probably use that same folder)

The changing of directories back and forth is still important for possible gotchas of /Library/ being cached.

It’s also quicker: 43 seconds in my tests.

🎉

Accepting PRs from whomever needs this.