`craft` target for Unity

[bruno-garcia]

We're setting up craft with the new Unity SDK.

CI is already configured in a way that we use the GitHub artifacts provider and craft prepare x.x.x already works as expected. Release registry has a new SDK: upm:sentry-unity and is configured already.

What we're missing now is the target to get craft publish to work.

We've identified two tasks to do that:

1. The github target currently downloads the artifact, unzip it, and publish all files in that artifact to the github release.
   
   This isn't the expected behavior for Unity, so ideally we'd just skip attaching anything to the github release altogether.

One alternative is to zip the files before adding as attachment. And having the target (see below) unzip to move to package

2. The actual 'release' for UPM is to replace all contents of a folder in the repository itself, and push it to the main branch.
   More context about the release process in this issue, and the contributing docs.

[BYK]

This isn't the expected behavior for Unity, so ideally we'd just skip attaching anything to the github release altogether.

We need more details here re "this isn't expected behavior for Unity". What is the expected behavior if we consider we should always have some release artifacts attached to our releases?

One alternative is to zip the files before adding as attachment. And having the target (see below) unzip to move to package

This sounds like a good approach to me.

The actual 'release' for UPM is to replace all contents of a folder in the repository itself, and push it to the main branch.

Replace the contents of package directory with the contents of the artifact.

The release folder is src/package. In order to make a release, the contents of src/package-dev/Editor and src/package-dev/Runtime folders should be copied into src/package.

None of this provide the context around why this is the way. It feels quite backwards and broken so I'd love to hear more about the reasoning around this process first.

[bruno-garcia]

This isn't the expected behavior for Unity, so ideally we'd just skip attaching anything to the github release altogether.

We need more details here re "this isn't expected behavior for Unity". What is the expected behavior if we consider we should always have some release artifacts attached to our releases?

Context is below.

One alternative is to zip the files before adding as attachment. And having the target (see below) unzip to move to package

This sounds like a good approach to me.

Yeah, let's go this way for the github attachment side of things.

The actual 'release' for UPM is to replace all contents of a folder in the repository itself, and push it to the main branch.

Replace the contents of package directory with the contents of the artifact.

The release folder is src/package. In order to make a release, the contents of src/package-dev/Editor and src/package-dev/Runtime folders should be copied into src/package.

None of this provide the context around why this is the way. It feels quite backwards and broken so I'd love to hear more about the reasoning around this process first.

The reason is in the links I provided.
More context on Unity's documentation: https://docs.unity3d.com/Manual/upm-git.html

[BYK]

So combining the information available on UPM docs and what you expressed here my understanding is us telling people to use git URLs, hence the need to put compiled assets back into the git repo and push that to main branch.

I have multiple different proposals to avoid this and use a method that does not require pushing compiled assets into the git main branch:

1. Build these assets in the bump-version script so they become part of the release branch and when we tag that branch, they become part of the code. Since release branches are also merged back to the main branch this should work both with and without the version (tag) suffixed URLs
2. Use https://forum.unity.com/threads/using-github-packages-registry-with-unity-package-manager.861076/ which uses GitHub's package registry feature for UPM consumption
3. Use NPM directly and our npm target and processes

Would any of these proposals work for you? My preference is 3 > 2 > 1 as 3 is the most standard and easy way and 1 is the least standard way that requires some special work.

[bruno-garcia]

Regarding option 2 and 3: A key part of this is how the user will install the package. They don't have a package.json in their project and they are not interacting with npm directly even though that's the package format.

Also on option 2:

GitHub's package registry

This requires auth so I don't believe we should pursue this approach.

About option 1:

Build these assets in the bump-version script so they become part of the release branch and when we tag that branch, they become part of the code. Since release branches are also merged back to the main branch this should work both with and without the version (tag) suffixed URLs

We already build it as part of the release. If I understand the idea is that instead of creating an artifact with the result, do move the files already to package and commit to that branch? This could be a solution though the downside is that it'll trigger another build of that branch and we should avoid doing the same thing again.

There's a 4th solution: We create a new repository, i.e: getsentry/sentry-unity-package and the release process will take the artifact we currently build and simply replace all content of that repo with the content of the artifact. We'd then add a tag there with the same tag we're releasing on the source repo (getsentry/sentry-unity). The advantage of this approach is:

1. We can limit write access to this repo so the getsentry/publish approval-based process works best. Essentially splitting write-access to the dev repo from being able to make a release
2. Simplify the installation process for customers: Instead of installing ..sentry-unity?path=/package#version it'll be ..sentry-unity-package#version
3. We avoid this odd release process that pushes artifacts to the develop repository

What do you think?

[bruno-garcia]

Sorry my initial description didn't cover some context that clearly was needed. Indeed it's a questionable release process to begin with so more reasoning will hopefully help:

To elaborate a bit more on why we're pushing towards using upm with git, from all installation options Unity provides, this is the most convenient. The tarball approach requires a file in the filesystem so it would be: Download this, open it like that.

One thing we want to support in the future is OpenUPM but this would be an alternative since it's more work on the side of the user unless they already have OpenUPM setup on their project.

[bruno-garcia]

To update this issue with the last comment from the pair "Unity Release" issue:

Currently the "upm target" is taken by these steps:

export release=0.0.6
export artifact=where/craft/downloaded/artifact
git checkout git@github.com:getsentry/unity.git
cd unity
git rm -r .
unzip $artifact/package-release.zip -d .
git add .
git commit -m "release $release"
git tag $release
git push origin main --tags

It's something that @bitsandfoxes is looking into to get into craft.

[BYK]

Closed via #209