Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package Testing Hangs if Package Being Tested is the Root Directory of the Repository #223

Open
trudeaua21 opened this issue Jun 10, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@trudeaua21
Copy link
Contributor

Bug description

When testing a package, if the package is the root directory of the repository, the test runner hangs at least as long as the default timeout for GitHub Actions.

By "package is the root directory of the repository", I mean that the repository structure is as follows:

ROOT
-> README.md
-> Editor
-> Runtime
-> Tests
-> package.json
...

The opposite case, where this problem does not occur, is when the package is not the root directory of the repository, meaning that the repository structure is as follows:

ROOT
-> README.md
-> com.example.packagename
---> Editor
---> Runtime
---> Tests
---> package.json

How to reproduce

  1. Take a Unity Package (preferably one which has been successfully tested with the test runner already), and upload it into a GitHub repository of it's own, such that the directory containing the package is the root of the repository.
  2. Run the test runner on the repository, passing a value of . to the projectPath input for the action.
  3. Observe that the test runner hangs.

Expected behavior

It would be expected for a package in the root of the repository to work the same as a package stored in a subdirectory of the root of the respository.

Additional details

A while ago, I dug into this to try to finish it before the completion of the package testing feature, but to no avail. Here are the comments on the original package testing issue and PR which discuss this problem:

Here is my in-depth info dump on the problem

Here is a description of a workaround I performed

@trudeaua21 trudeaua21 added the bug Something isn't working label Jun 10, 2023
@trudeaua21
Copy link
Contributor Author

Leaving this here for visibility: the workaround I linked to in the issue was a bit hacky, but it got the job done.

Essentially, I just copied the entirety of the root directory of the repository into a subdirectory, then passed that subdirectory in for the projectPath input, which then allowed the package to work correctly.

Here's a direct link to the workflow file where I did this, and below is the specific step in my workflow I used to do the folder copy:

      - name: copy dir to new dir
        run: |
          pwd
          folderName=$(echo "${PWD##*/}")
          rsync -r "$GITHUB_WORKSPACE" "copiedProject" 
          ls -F "copiedProject/$folderName"

# then later give the test runner the projectPath arg with the value ./copiedProject/WhateverYourProjectNameIsHere

All that said, it's not a pretty solution, and maybe not even the best way to do the folder copy itself, since I probably just whipped it up in a hurry back when I was trying to debug this.

shino-hinaduki added a commit to shino-hinaduki/ExpressionParameterImport that referenced this issue Oct 15, 2023
enitimeago added a commit to enitimeago/make-it-mmd that referenced this issue Feb 1, 2024
enitimeago added a commit to enitimeago/make-it-mmd that referenced this issue Feb 1, 2024
@cckelly
Copy link

cckelly commented Jun 19, 2024

Thanks @trudeaua21 - also leaving this solution for moving into a separate folder:

          mkdir -p unity-package
          shopt -s extglob
          mv !(unity-package) unity-package/
          shopt -u extglob

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants