jeffcampbellmakesgames/unity-package-tools

unity-package-tools meet OpenUPM

favoyang opened this issue · 5 comments

favoyang commented

Hi @jeffcampbellmakesgames,

Thanks for all the efforts for making quite a few open source upm packages.

I'm the creator of OpenUPM, a public upm registry with automatic build pipelines that publish new package bundle based on (semver) git tags. You can read the announcement on patreon or medium to get the basic idea, so far it hosts 90+ packages as of December 2019.

I would like to add your packages to the platform, but I meet an issue with the way unity-package-tools work. AFAIK the tool

  • Stores a package info file at Unity/Assets/PackageManifests and the generated package.json at Unity/Assets/PackageManifests/Generated/<hash>/package.json
  • Package source code folder located at unity-package-tools/Unity/Assets/JCMG/<package-name>/
  • releases/stable branch is the clean upm branch to feed unity package manager
  • github releases (git tags) are based on master branch and attached traditional .unityPackage file

OpenUPM is a public upm registry with automatic build pipelines. The build pipelines:

  • monitor the releases on GitHub project
  • find git tags that are valid semver
  • located the package.json path
  • build package and publish to openupm registry

The issue is that the OpenUPM build pipelines can not find the package.json file in your GitHub releases, because what you git tagged is the "source repository" not the "upm package". I'm thinking about two options to make they work together.

Option1: create GitHub releases based on releases/stable branch in future. Then all these vx.y.z branch will be valid upm branch. Can be resolved by unity package manager, OpenUPM, and UpmGitExtension. This would be the most easy way to go, and in general will benefit the package version control.

Option2: change the generated package.json path to unity-package-tools/Unity/Assets/JCMG/<package-name>/package.json, so you always keep a valid upm structure in master branch, for the OpenUPM build bot to process.

Option3: this changes too much, so I won't suggest it for this time. But I share my 2 cents here. I think a better approach would be put the package source folder at Packages/<package-name>. This way the package acts as a local upm package, you can fully test it with the example project. You can also write a tool to directly maintain the package.json file, instead of write a custom manifest.

jeffcampbellmakesgames commented

Hi @favoyang, thanks for taking the time to share UPM with me.

Option1: create GitHub releases based on releases/stable branch in future. Then all these vx.y.z branch will be valid upm branch. Can be resolved by unity package manager, OpenUPM, and UpmGitExtension. This would be the most easy way to go, and in general will benefit the package version control.

Most of my projects have the same structure as this one and if I were to try and support UPM I would rather go with this approach of applying the git tags to the releases/stable branch. Couple of questions for you:

  • Does UPM support different distro branches for a package as well, such as a development and release package?
  • What next steps should I be looking to take and verify UPM support using the first option above?
  • What can I add to my readme to demonstrate or help show that this library supports UPM?

Thanks and looking forward to hearing more from you.

favoyang commented

Hi @jeffcampbellmakesgames,

Thanks for the response. I agree with you that the option 1 is the most affordable option here.

Does UPM support different distro branches for a package as well, such as a development and release package?

Our build pipelines monitor only git tags that conform semver format. Like 1.0.0, v1.0.0 and path-like prefix stable/releases/1.0.0, upm/1.0.0. As long as you create GitHub releases (git tags) from your dev/release branch with different version string, it shall work.

What next steps should I be looking to take and verify UPM support using the first option above?

  • (Optional) bump version and update the stable/release branch.
  • Create a new git tag from the stable/release branch, named upm/x.y.z.
  • So in future release you will create two tags x.y.z from the master branch and upm/x.y.z from the stable/release branch. If you think it''s not necessary to keep the master branch release, you can create x.y.z tag from stable/release. But either way works.
  • Submit your package to OpenUPM https://openupm.com/packages/add/.
  • Wait the CI to process, verify the result at the build issues section. You shall see your previous releases failed (because of missing package.json) and new release succeed.

What can I add to my readme to demonstrate or help show that this library supports UPM?

You can find the badge on the package detail page. And you can also update the installation options like this one https://github.com/favoyang/unity-addressable-importer#install-via-openupm

  • 👍1
jeffcampbellmakesgames commented

Thanks for the quick response. I've reconfigured this GIT repo's tags and have added UPM-style tags on my release branch and have been able to successfully upload a package for this library to OpenUPM.

https://openupm.com/packages/com.jeffcampbellmakesgames.packagetools/

  • 👍1
favoyang commented

@jeffcampbellmakesgames thanks for making more progress.

I have seen you submitted two packages to the platform. Here's some tips

  • When adding new package, if you leave PR title no change (chore(data): new package...), it will be merged by bot automatically, so you don't need to wait.
  • I modified your yaml by adding a git tag prefix upm/ (there'a field on the package submission form). It tells our build pipelines to ignore your old releases (which is vx.y.z format) to avoid issues.
  • 👍1
jeffcampbellmakesgames commented

Thanks, I will remember that for future additions 👍

  • ❤️1