Another approach for Personal license users

[jcs090218]

Hi,

I recently came up with another approach to deal with manual license activation for free users (like myself). I have extended package unity-license-activate (it was originally created by Mizo Take), so it can be used inside the CI pipeline. This is a simple CLI program that uploads the .alf file and then downloads the .ulf file from Unity’s site. The last step to adapt to the rest of the CI workflow is to create/update the GitHub secret (UNITY_LICENSE)!.

I have used this pipeline for these few days and it works very well and stable. 😀 I think it would be great if this workflow can officially be part of the GameCI. Especially for users who aren't using Unity Plus/Pro version! What do you guys think! ?😖

Full example

• https://github.com/jcs090218/JCSUnity/blob/master/.github/workflows/license.yml

Packages

• https://github.com/jcs090218/unity-license-activate (main)
• https://github.com/jcs090218/unity-verify-code

[jcs090218]

I have split the CI pipeline to one single workflow (license.yml)! Now it runs in schedule base, so it won’t have to update the license every time you pushed! The link is updated in the first post! :)

[webbertakken]

Great! I'll have a closer look next week.

[webbertakken]

First of all, thanks for sharing your approach with the community. This specific topic has been discussed a few times before, but so far nobody had seen the chance to contribute back, so I'm very excited to see this great example for a start.

There are a few things I'd like to clarify with regards to composition of components and our philosophy for the unity actions in GameCI, that might help make the right decisions moving forward with this feature.

We create CI for games for everybody; new developers working with CI for the first time, up to big companies with their own DevOps teams having possible SLAs or restrictions and security compliance as well as endless parallelisation.

In practice we've found that it works well to especially keep in mind new developers. We do this by reducing the number of separate actions and simplifying the public facing API, keeping it functional rather than technical where possible.

To implement this feature we might consider

• Directly implementing the logic inside both unity-builder and unity-test-runner (perhaps somehow abstracting out some core logic into a runner-base project?) instead of using separate actions for each step.
• This would make it that much easier for the end-user as well as reduce the amount of needed documentation.
• This would also mean having to (optionally?) ask for the GITHUB_TOKEN, to write the secret for the .ulf-file (in case it's not set? overwrite after every failure?).
• That in turn would come with a security concern for the latter group. To mitigate this we might need to either move the repositories for these npm packages (or their relevant code) inside the GameCI organisation. Maybe there are more options?

This may or may not be what you had in mind though. I'm putting this out here as a basis for an open discussion on how to implement this for Unity Actions of GameCI, to be usable by all.

[jcs090218]

This would also mean having to (optionally?) ask for the GITHUB_TOKEN, to write the secret for the .ulf-file (in case it's not set? overwrite after every failure?).

Can we feed the .ulf file directly to the next workflow? Then we can remove UNITY_LICENSE and GITHUB_TOKEN for free users. There are many approaches to this, not sure what's the best solution. 😮

That in turn would come with a security concern for the latter group. To mitigate this we might need to either move the repositories for these npm packages (or their relevant code) inside the GameCI organisation. Maybe there are more options?

I am fine to move these repositories to the GameCI org. These are designed to use with GameCI in the first place. 👍

[jcs090218]

@webbertakken Hi, it has been a while since last discussion. Wonder what's our next step here?! Do you want me to move the two repos to the org? Or maybe another approach? Let me know your thoughts!

[webbertakken]

Hi @jcs090218, thank you for your message.

Short term I think we're open to moving these actions to GameCI. Mid-to-long term I believe the best way forward is to integrate activation logic into both test-runner and builder. That way we can simplify setup of workflows for the end user, by deprecating request-activation-file over time, as well as some or all actions mentioned in the OP and any other activation related action. If you ask me this would both clean up the landscape and make setup easier for everyone.

Is this something you would consider? I'm also curious to hear what would be your suggested course of action.

Please also note the following context: We're still looking into consolidating core logic for test-runner and builder actions into a shared kernel. We are aiming towards housing that kernel in the unity-actions repo, however we haven't figured out which method to use for it (e.g. using an npm package as a dependency or utilising composite actions or another GitHub Actions specific paradigms).

The goal is to stay as close as possible to best practices while making our code more maintainable. The entrypoint and public api for both actions would stay the same to prevent breaking changes. In the meantime the status quo is that we are still duplicating shared code in both repos, which works well but has the downside of some overhead.

[jcs090218]

Got it! Do you want to invite me to org, so I can transfer these two repositories? I would still like to maintain these two actions before we do any mid-to-long term goals! :)

Is this something you would consider? I'm also curious to hear what would be your suggested course of action.

I think the integration plan make sense since it should be easier for most free license users. Yet I am still not sure how things are get integrated without npm package being as a dependency. 😕 Other than this, I am confident with your mindset/plan here since these all make good sense to me. 👍

[webbertakken]

Ok, sounds good. If it's ok for you, please transfer the repos, then we'll provide you with maintainer status on those repos.

[jcs090218]

Great! How would you recommend me to start implementing this feature into kernel/core module?

[webbertakken]

When you say "this feature", you mean the activation or moving to shared kernel in a separate repository (which hasn't been done so far)?

We haven't come to a definite direction for the latter yet. But we're thinking of using GitHubs reference methods for that, like composite actions or other concepts they explain in their documentation.

As for incorporating the feature, probably best to start with unity-builder and then later port any functionality back to unity-test-runner.

[jcs090218]

No problem, and no rush on that. I think this isn't a high priority task since the present solution works for me! I might start look into some of the GitHub actions in this org. Let me know if you have sent me the org invitation, so I can transfer these repos!

[webbertakken]

Great! You have been invited as a member with read permissions. Once you transfer the repositories to game-ci we'll give you write permissions to them.

[jcs090218]

Joined and transferred! Thanks! :)