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

[REG-1495] Reorganize Unity projects and add CI/CD #121

Merged
merged 10 commits into from
Dec 11, 2023
Merged

Conversation

analogrelay
Copy link
Contributor

@analogrelay analogrelay commented Dec 8, 2023

Warning

When this PR merges, all references to our SDK will have to be updated.
This applies to:

  • Anyone using our builds from main
  • Anyone using our builds from 0.0.16 (next release) on.
    In addition, we need to update our README when we ship 0.0.16 to provide the correct Git URL.

Note

There's a lot here. I recommend reviewing it commit-by-commit, as it's easier to follow. Use the dropdown in the top-left of the PR review panel:
image
The first commit moves the existing package in to src/gg.regression.unity.bots and the second commit adds the RGUnityBots project. From there, I'll be adding additional scripts for CI/CD.

This PR refactors our repo so that it has our package, and a "Host" Unity project:

  • src/gg.regression.unity.bots - The RegressionGames Unity SDK package.
  • src/RGUnityBots - A barebones 3D Unity game that is used to build and test the Unity SDK package.

The RGUnityBots Unity project references gg.regression.unity.bots via a relative path, so if you build it or run tests, it can validate the Unity SDK itself.

Compilation errors are rendered in the PR files list!

image

Test results render in the "Details" view for the "Unity Build and Test / Test Results" PR Check:

image

TODO:

Blocked by:

  • I need a Unity License we can use for building
  • We need to configure that Unity License in the GitHub Actions Secrets for this repo (I don't have permissions for that).

Find the pull request instructions here

Every reviewer and the owner of the PR should consider these points in their request (feel free to copy this checklist so you can fill it out yourself in the overall PR comment)

  • The code is extensible and backward compatible
  • New public interfaces are extensible and open to backward compatibility in the future
  • If preparing to remove a field in the future (i.e. this PR removes an argument), the argument stays but is no longer functional, and attaches a deprecation warning. A linear task is also created to track this deletion task.
  • Non-critical or potentially modifiable arguments are optional
  • Breaking changes and the approach to handling them have been verified with the team (in the Linear task, design doc, or PR itself)
  • The code is easy to read
  • Unit tests are added for expected and edge cases
  • Integration tests are added for expected and edge cases
  • Functions and classes are documented
  • Migrations for both up and down operations are completed
  • A documentation PR is created and being reviewed for anything in this PR that requires knowledge to use
  • Implications on other dependent code (i.e. sample games and sample bots) is considered, mentioned, and properly handled
  • Style changes and other non-blocking changes are marked as non-blocking from reviewers

@vontell
Copy link
Collaborator

vontell commented Dec 11, 2023

@analogrelay I went and add the Unity license to the UNITY_LICENSE secret in GitHub Actions for this repository - let me know if you need any other permissions, but I believe that should work...

@analogrelay
Copy link
Contributor Author

I think that's all I needed, but I'll let you know!

@analogrelay analogrelay force-pushed the ashley/reg-1495 branch 2 times, most recently from fe5127f to ebdd47e Compare December 11, 2023 19:11
@analogrelay analogrelay marked this pull request as ready for review December 11, 2023 20:23
@nAmKcAz
Copy link
Collaborator

nAmKcAz commented Dec 11, 2023

@analogrelay For the projects we have that reference the sdk by relative path, the PRs for the update can be made beside this for review (that's what I've generally done in the past so they can all merge near in time)

BossRoom
PlatformerSample
HappyHarvestBot-Sample
... others ??

For the GIT reference projects.... needing to update to the latest commit after merging is annoying and prevents the early PRs for the most part. IIRC I think I used unity's package manager to update those hashes after merging last time but there are other ways to do it.

Copy link
Collaborator

@nAmKcAz nAmKcAz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

If we don't have at least one gotcha from this I'll be amazed/impressed, but only one way to find out for sure. Merge it 👍

I wonder if in the future we can do another pass where we put the sample projects we wish to ship in an easier to manipulate location and package them into the SDK during the build.

Copy link
Collaborator

@vontell vontell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very excited about the possibilities this opens up...

Just to confirm one thing though - when we download via git for the package, it was unclear to me whether the game samples also would be downloaded? Now that I think about it, even though we can define a folder, would the git clone still pull everything?

Comment on lines +34 to +41
- name: Run Unity Tests
id: run-unity-tests
uses: game-ci/unity-test-runner@v4
env:
UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
with:
projectPath: src/RGUnityBots
githubToken: ${{ secrets.GITHUB_TOKEN }}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So right now this will only run the tests in the SDK, correct? And in the future how should we run tests that are in the games? Also I am guessing we will have a README in this project that mentions things like this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This builds and run tests on the host project src/RGUnityBots. Ideally, this should be where all our tests live. If we need scenes or assets for test scenarios, I'd suggest they mostly live in src/RGUnityBots so that they aren't expected to be both useful tests and useful samples (as those scenarios can be different).

When/if we add other samples to this repo, we can absolutely add GitHub Actions workflows to build and test them. The "primary" build here is src/RGUnityBots though.

@analogrelay
Copy link
Contributor Author

One piece of clarification: This PR introduces no additional samples into this repo. We can absolutely start merging our existing samples into this repo but I haven't done that immediately because each sample needs a little evaluation to ensure we have an appropriate license to redistribute it since this is a public repo. Our samples are almost entirely from "open-source" content and our own original work, so this should be straightforward, but I didn't want to jump straight in to that right now.

I wonder if in the future we can do another pass where we put the sample projects we wish to ship in an easier to manipulate location and package them into the SDK during the build.

@RG-nAmKcAz

This is largely my plan, though I'm saving it for future PRs. I think the src/gg.regression.unity.bots/Samples~ directory is still necessary and should include the core sample content intended to be packaged "with" the SDK, like our ThirdPartyDemo sample.

We also have the option, in this layout, of creating samples that live outside the SDK package itself, in the samples/ directory (doesn't exist yet). These would be samples we could build and even test as part of building this repo, and are available to users who clone the repo and want to look through more detailed samples, but they don't appear as "part" of the SDK.

Just to confirm one thing though - when we download via git for the package, it was unclear to me whether the game samples also would be downloaded?

@vontell

The Unity SDK package is now in src/gg.regression.unity.bots. This is what you reference in your projects, so out-of-repo projects (some of our samples, and customer games) can either:

  • Clone this repo and use a file-system reference in to the src/gg.regression.unity.bots (then it's up to them to manage the repo on-disk)
  • Make a Git reference using the ?path syntax to specify the path to the package, for example: https://github.com/Regression-Games/RGUnityBots.git?path=/src/gg.regression.unity.bots#0.0.16. Unity will clone the repo and handle the reference.

In either case, only the SDK (src/gg.regression.unity.bots) will be integrated into their game. Other files in this repo (such as future samples we put in this repo) will end up on disk (I expect Unity will clone the entire repo) but only the SDK folder contents will end up as Assets in their project.

@analogrelay
Copy link
Contributor Author

For the projects we have that reference the sdk by relative path, the PRs for the update can be made beside this for review (that's what I've generally done in the past so they can all merge near in time)

Yep, that's what I'm working on now.

@vontell
Copy link
Collaborator

vontell commented Dec 11, 2023

@analogrelay ah yes I guess my concern was the following - I thought the point of this PR was to begin supporting putting our samples into this repo, which sounds like the next steps. However, I am more worried now about the idea that if we do start adding samples, then when a user goes to add our package, even though our SDK folder would be small, they would need to pull gigabytes worth of sample projects that then get thrown away by Unity anyways. That was what I was getting at with my comment, if that makes sense!

@analogrelay
Copy link
Contributor Author

analogrelay commented Dec 11, 2023

I thought the point of this PR was to begin supporting putting our samples into this repo

I don't believe that's the case. The point of the PR is to be able to build and test the SDK. The fact that we can put samples in here is a bonus, but it's entirely an entirely separate decision IMO.

@vontell
Copy link
Collaborator

vontell commented Dec 11, 2023

I thought the point of this PR was to begin supporting putting our samples into this repo

I don't believe that's the case. The point of the PR is to be able to build and test the SDK. The fact that we can put samples in here is a bonus, but it's entirely an entirely separate decision IMO.

Ah got it - makes more sense now! Thanks!

@analogrelay
Copy link
Contributor Author

I opened PRs against all our samples, but I want to merge this and my other outstanding PRs first, then update those PRs. For a few reasons:

  1. I may need commit hashes updated
  2. We can get those samples updated with the latest codegen after [REG-1463] Generate 'partial' class to attach RGState and RGAction to host behavior #116 lands.

So, the plan for now is to merge this, then update my other PRs to resolve conflicts (since trying to resolve conflicts here would be a lot).

@analogrelay analogrelay merged commit 06842de into main Dec 11, 2023
2 checks passed
@analogrelay analogrelay deleted the ashley/reg-1495 branch December 11, 2023 22:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants