License usage

[mathstuf]

Hi, we're interested in using these scripts to test FindMatlab in CMake. However, we use GitLab-CI; what is the license situation for using the scripts here for our CI purposes? Thanks.

[mcafaro]

Hi @mathstuf,

The install scripts will not license MATLAB on GitLab CI and are really intended to work only on the handful of CI services we currently support (Azure Pipelines, CircleCI, GitHub Actions, and Travis CI).

For a GitLab project, you may consider running your own GitLab Runner where you have pre-installed and licensed MATLAB. Another option would be to use Azure Pipelines with a third-party GitLab integration (note: I have not tried this myself). CircleCI also claims to be working on GitLab support, targeting general availability for the second half of the year.

Best,
Mark

[acampbel]

Want to +1 Mark's comments. Are you using gitlab hosted shared runners or do you already leverage your own runners? If the former then I think Mark's suggestion is the way to go. If you wanted to leverage gitlab hosted shared runners, there is not currently an official solution but we'd love to work with you to try to see how we can possibly help. Also, as Mark says, using a supported platform like Azure Pipelines or CircleCI might be able to help you use a shared runner hosted service, but we should actually confirm this would work with what you are doing before going all in on that approach.

Let us know if you'd like talk more about what you are doing if there are challenges using self hosted runners or a supported CI platform.

[mathstuf]

We host our own GitLab instance with our own runners. However, we only use Docker containers for Linux (so far). We do use "bare metal" for macOS and Windows, but we really try to keep the machines as "clean" as possible so that there's little in the way of machine-specific setup and it'd be nice to just be able to download an SDK and extract it as part of the CI steps. I expect any bare metal Linux runners to follow a similar pattern. However, just getting Linux/Docker testing would be a good first step at least.

[acampbel]

Sure, you should be able to generate a MATLAB container and/or utilize mpm apis but you are right in the comments at the bottom of this page that you'll need to think about licensing. Does your gitlab server have access to a license server? If so you can utilize a named network server license to enable licensing.

[mathstuf]

I know we have some licenses; I'll ask about what kinds they are, how they are stored, and whether we can set up a network server for them for CI to use. Thanks.

[acampbel]

sounds good. If you run into challenges with your existing licensing setup, feel free to connect with us at continuous-integration at mathworks dotcom and we can try to help you get unblocked with this. We'd like to help you get this going.

[mcafaro]

CircleCI recently announced GitLab support: https://circleci.com/blog/announcing-gitlab-support/

[mathstuf]

Does that work with only gitlab.com or is it any GitLab installation? I don't see it mentioned there at least.

[mcafaro]

@mathstuf Good question. I tried it and they have a "GitLab Self-Managed" option in the drop down, but it says "Coming Soon" if you select it.

[aleksandaratanasov]

Hi @mathstuf,

The install scripts will not license MATLAB on GitLab CI and are really intended to work only on the handful of CI services we currently support (Azure Pipelines, CircleCI, GitHub Actions, and Travis CI).

For a GitLab project, you may consider running your own GitLab Runner where you have pre-installed and licensed MATLAB. Another option would be to use Azure Pipelines with a third-party GitLab integration (note: I have not tried this myself). CircleCI also claims to be working on GitLab support, targeting general availability for the second half of the year.

Best, Mark

I am currently waiting for a call from MathWorks regarding the shared runner. I have set one up just for me to see if it works at all before going forward. Some people online claim that you cannot use such a runner unless you have a concurrent network license. In my case we have very few network named user licenses (I am currently a holder of the Matlab Compiler one). I have set up the GitLab runner to be a service bound to my own user account (you can restrict a runner that way). Further in the CI one can restrict jobs by user ID (e.g. only if user XYZ pushes CI job ABC will be triggered).

My current setup involves the Matlab Compiler/Compiler SDK toolbox. The only current unknown is how a local GitLab runner is affected by Mathworks' licensing model. Basically I have come up with the following conclusions:

• a compiled Matlab executable binary does NOT require licenses for the toolboxes that it contains (albeit some functionalities of those toolboxes may be missing as described on the official compiler support for toolboxes page. You still need the licenses for the development of the code but once you create the EXE, it's no longer an issue
• a compiled Matlab executable binary needs only MCR as well as (if used) any external DLL/SO files, which are not really bound to any Mathwork license (e.g. I have Matlab code that is interfacing the GDAL library for GIS data processing)
• the MCR is freely distributed and can be installed and run inside a Docker container

Basically my approach (unless my call with Mathworks explicitly points out that it's against the license agreement, in which case I will require absolute and precise proof for that and will involve our legal team) is to automatically generate wrapper code that loads a workspace with all required variables by the original Matlab function/script or provides automated facilities for parsing CMD line arguments (you can use eval for loading a string that contains all required variables inside the runtime of Matlab). Running the wrapper code plus the original code through the MCC via the local GitLab runner I can upload the resulting executable binary (capable of loading e.g. a workspace from a MAT file) and then use it in follow-up jobs, e.g. testing or more without worrying I am breaking any license agreement since the code is running on MCR.

The alternative is very pricey since concurrent licenses are 4-5 times more expensive AND you also have to provide a license for every toolbox involved, since your CI will be running pure Matlab code (not compiled one). To put it in simple terms, with just a few toolboxes such a setup may cost you several thousands or even tens of thousands of USD per year. We are currently paying over 80K for a vast number of toolboxes with few network named user licenses in the pool. If we have to switch to the concurrent version, we will go broke. LOL

[acampbel]

Folks watching this issue may be interested in the batch token licensing pilot. More information can be found in the link below (in a Docker context, but also applies to other approaches such as these GitHub Actions)

https://github.com/mathworks-ref-arch/matlab-dockerfile/blob/main/alternates/non-interactive/MATLAB-BATCH.md