License from secrets is working but not from environment variable

Hi, I’m running unity application build jobs on self-hosted github runner. I am saving license data in github secrets and it works fine. However, this license is binded with machine and with multiple runners I cannot store license in the secrets anymore. However, I am storing license in environment variable and returning it with echo step like this

...
- name: get license data from file
        id: unity_license
        run: |
          echo ::set-output name=host::$HOSTNAME
          echo -e "::set-output name=file::$UNITY_LICENSE"
- uses: game-ci/unity-builder@v2
  env:
      UNITY_LICENSE: ${{ steps.unity_license.outputs.file }}

...

But doing so doesn’t work and gives invalid license error. Same content in the secrets works completely fine. I’ve lot of things but nothing seems to work with this approach. Can you please help me figure out what I’m doing wrong?

1 Like

Your workflow snippet does not include the part where you set $UNITY_LICENSE. Are you sure that ${{ steps.unity_license.outputs.file }} is actually set properly?

Yes, $UNITY_LICENSE is configured and value exists there. However, it is long data. I’m facing problem with multiple line data from $UNITY_LICENSE. It is xml file including licensing stuff. Also is there any character limit on environment variables set in github actions bcoz I haven’t encountered such thing in docs.

Sorry, I wasn’t asking for the content of the license file, just the workflow code that sets the environment variable. IIRC, then there are issues with setting multi-line outputs, maybe also with setting environment variables. I would need to take a look at the code that you use to set it. The documentation has an example of how to set an environment variable using environment files for the multi-line case: Multiline strings

Unity license is machine specific so I’m setting it with slight modification of original code of github runner. However, the problem is that I’m not getting the full license content, could be character limit issue of environment that I’m not aware of. Do you know what can be issue? Still, I’ve managed to get it working with secrets as a workaround. And thanks for the doc link, I’ve seen that page but that was not there.

Going back to your original question, do you have just one license that you want to use on multiple machines, or do you have multiple machines and a license for each?

With one machine-specific license per self-hosted runner, it shouldn’t be necessary to handle the license file in any workflow at all, as you could simply activate Unity on each machine once because the host state is persistent. Or do you use virtualization like GitHub-hosted runners do, i.e. get a fresh (virtual) environment for each workflow run?

As discussed in set-output Truncates Multiline Strings, setting a multiline output in a step won’t work unless you escape certain characters (but some users say that they can’t get that to work either).

I’m still not sure how $UNITY_LICENSE is initially set. Does Unity create this environment variable upon installation? And is it the path to the license file or the actual license file content?

$UNITY_LICENSE is machine specific and each machine will have different license. It is the variable I’ve configured on runner machine to use it in workflow environment. Now challenge is that while building project I have to provide the license to build step. Yes, I can save the license in the file and save at accessible path but the environment variable holding the license is elegant solution. I would emphasize on fixing this

As discussed in set-output Truncates Multiline Strings, setting a multiline output in a step won’t work unless you escape certain characters (but some users say that they can’t get that to work either).

What happens if you simply don’t set UNITY_LICENSE where you use the game-ci/unity-builder@v2 action? So - uses: game-ci/unity-builder@v2 without the env: UNITY_LICENSE: ... part. If there is an environment variable UNITY_LICENSE already set on the host machine, shouldn’t it just work?

I believe they tell you to set this environment variable because most people use GitHub-hosted runners or other cloud machines that require activation, but with self-hosted runners it’s a different situation.

Also take a look here: unity-builder/activate.sh at 9fff3627757a76db932be572b62521043322e901 · game-ci/unity-builder · GitHub
Looks like you can also specify a file path to the license file instead of the license data itself via the environment variable UNITY_LICENSE_FILE.

What happens if you simply don’t set `UNITY_LICENSE` where you use the `game-ci/unity-builder@v2` action? So `- uses: game-ci/unity-builder@v2` without the `env: UNITY_LICENSE: ...` part. If there is an environment variable `UNITY_LICENSE` already set on the host machine, shouldn’t it just work?

Nope it doesn’t work, I didn’t know the reason and move passed it assuming that it may be because of some mechanism used by github-runner application. And about UNITY_LICENSE_FILE, don’t remember exactly but I did try something like that and it also didn’t work. I would like to give it a try, thanks for the effort :slightly_smiling_face:.

Well, in that case, it might indeed have something to do with the runner not forwarding the host environment variables to the action. You could try setting a multiline environment variable via environment files, which should then be available in all subsequent steps without explicitly setting env: UNITY_LICENSE: ...:

      - name: get license data from file
        id: unity_license
        run: |
          echo ::set-output name=host::$HOSTNAME
          echo 'UNITY_LICENSE<<EOF' >> $GITHUB_ENV
          cat $UNITY_LICENSE >> $GITHUB_ENV
          echo 'EOF' >> $GITHUB_ENV
      - uses: game-ci/unity-builder@v2

Even if this works, I think it’s still better to use secrets because secrets don’t get logged whereas the above will probably leak the full content of the license file to the workflow run log.

I thought exactly that.

I think that github-runner application should natively support feature like secure environment variables that do not log when used in workflows. That is better option if something is host machine dependent like in unity license case.

1 Like