sschmid / Entitas

Entitas is a super fast Entity Component System (ECS) Framework specifically made for C# and Unity
MIT License
7k stars 1.11k forks source link

Publishing Unity packages to openupm #1048

Open sschmid opened 1 year ago

sschmid commented 1 year ago

@JesseTG I wanted to double check with you: I'm not sure if I over-complicated things with releasing Entitas to openupm.

Current setup: I have a couple of C# projects, e.g.:

Jenny, DesperateDevs, Sherlog, TCPeasy, Entitas coming soon

and I would like to release NuGet packages to NuGet and Unity packages to OpenUPM.

In order to achieve this I have 2 repos each. The actual repo containing the C# project, and another one that is used to transform the C# project into the Unity package format.


I added GitHub actions, see: https://github.com/sschmid/Entitas/tree/main/.github/workflows

CI

CI builds on push and does this:

and uploads assemblies and NuGet packages to the workflow run. This allows you to download the latest assemblies when pushing to main or to a PR.

Release

Release does the same as CI plus:

to upload the assemblies to NuGet.

To release a new NuGet package I can just pick a tag and run the Release workflow.


I have separate repos for the Unity packages, e.g.:

com.sschmid.jenny, com.sschmid.desperatedevs, com.sschmid.sherlog, com.sschmid.tcpeasy

These repos contain an empty Unity project + a submodule for the actual repo.

The only job of this repo is to update the submodule, generate and update asmdefs and package.json, see GitHub action:

https://github.com/sschmid/com.sschmid.sherlog/blob/main/.github/workflows/release.yml

This action does this:

The build.bash script gets all project and package references needed to generate asmdefs and package.json.

While this step is not that complicated, it feels way to complicated and I was wondering if there are easier solutions.

How would you design the release workflows to be able to publish to NuGet and OpenUPM?

pereviader-popcore commented 1 year ago

I think It looks great, opening unity to generate might be a bit slower due to it generating it's internal library and initialising itself but it's definitely the most future proof solution.

The only thing I'd change, if possible, would be to not need to make a repo for each unity package. I think a single shared "unity package builder repo" would be more scalable. Then implement a github action which will pull the builder repo and setup the repo to build inside it like the submodule is doing now. Then setup workflows on each of the main repos that call this github action

sschmid commented 1 year ago

Unity meta files should persist, so the "unity package builder repo" would potentially contain all projects, right? Every release will result in additional commits to persist meta file changes which makes it risky to build multiple projects in parallel. For parallel build 1 builder repo per project seems better.

If it wouldn't be for the meta files, ideally I just have 1 build repo that doesn't contain anything expect a default unity project.

pereviader-popcore commented 1 year ago

Was not thinking about the metas you are right. If you are fine with having a UPM branch on the other repos instead of a specific repo for the "upm" release. Making the github action I mentioned before create a separate commit tree for the upm branch is an option. https://github.com/PereViader/ManualDi.Main/tree/main https://github.com/PereViader/ManualDi.Main/tree/upm

The last step on this action pushes to that other UPM tree https://github.com/PereViader/ManualDi.Main/blob/main/.github/workflows/publish-unity3d-package.yml

This supposed github action would need to create an orphan UPM branch when it does not exist which can be done with git checkout --orphan

Otherwise having a repo for each UPM release is also not that bad.

JesseTG commented 1 year ago

You can also generate the .meta files yourself. They're nothing special, the only thing you really have to do is provide your own GUID.