LabVIEW Continuous Integration License?

[Taggart]

I was about to suggest you talk to Christian, but he beat me to it.

[Taggart]

The seperate activation is awesome, because now you could use  Vagrant with VMware for Dev systems. Just store the license key in a environment variable and have vagrant register it when it starts up. So just setup one Vagrant box for a project with all the drivers you need and then you can distribute it to the whole team.

[joerg.hampel]

---

@cbutcher wrote:

---

---

Perhaps I misread Eric's comment, but I got the impression that the goal with 2021 (I'm guessing that's the comment you're posting in relation to here?) is to allow installation in some image/VM/container/blob file on disk (whatever), but not activate it.

---

You're right, Christian, I misread Eric's comment (and he clarified it in the meantime).

Our own build machines are VMWare virtual machines hosted on an ESXi server running vSphere. These VMs are "always-on". The way we do things, they need to be alway on because they are running the runners/agents which receive and execute jobs directly on those VMs. FYI, our "CI/CD" customers mostly run physical build servers and don't use virtualisation yet.

Looking at our current situation, and how we use SCC-triggered server-side automation, I prefer having those build VMs running continuously. I can do without the time it takes for a windows machine to boot up - as I mentioned, we're constantly trying to optimise steps in our toolchain to make pipelines execute faster. 

Another point for us is that we reuse build VMs across projects where possible. We usually have one VM per LabVIEW version, as most of our projects are on RT/FPGA and don't involve drivers. So we don't have to create new VMs very often.

Still, I'm very curious about the new feature in 2021. Regardless of whether the VM/image/container is running continuously or not, we could still enable/disable the license with each job and end up with a pretty fast system.

@EricR, do you have a ballpark number for how much time the activation of a license would take?

[joerg.hampel]

---

@cbutcher wrote:

---

---

I had to go read a definition of "Continuous Integration" again to try figure out what you mean, but I'm still not certain. The definition I read does make it seem like Sam's comment on single-person setups falls away from CI, but for me, my Jenkins server has a few pipelines and one of those builds all of my PPLs for multiple targets. When I want to update code, I use a specific tag in my git commits and then it triggers builds via a GitHub webhook notification.

---

I really don't want to derail this thread, so I created a new one for this discussion.

[joerg.hampel]

---

@joerg.hampel wrote:

Looking at our current situation, and how we use SCC-triggered server-side automation, I prefer having those build VMs running continuously. I can do without the time it takes for a windows machine to boot up - as I mentioned, we're constantly trying to optimise steps in our toolchain to make pipelines execute faster. 

---

I want to change my position here a bit. Disk space is much cheaper than RAM, and it would indeed be handy to have some rarely used VMs stored on the build server and not always on. If they would spin up just in those rare cases where we need to build some exotic project, and if that would happen automatically, that would be handy.

[cbutcher]

---

@EricR wrote:

The main thing we added in 2021 is the ability to leave the LabVIEW layer unactivated (since you aren't sure of which computer you are spinning the image up on) and just calling the activation as a setup step using command lines/scripts.  You couldn't do that before so the activation step was always a pain.

---

So I'm really excited about this, but so far I didn't see anything about it in Readmes for LabVIEW, NILicenseManager or the /help argument to NiLicensingCmd dot exe (all the 2021 versions, weird formatting in the last bit to avoid a forum block).

Obviously it's only been ~1 day since these things were made available (at least that I noticed), but is there some information about using these options? (please let them not have been cut... :s )

This command: 

NILicensingCmd#exe /activateall /serialnumber <my serial number>

still popped up a GUI for me on my Windows dev machine, which makes me less confident it is the intended method.

(It also prompted me with the message "ERROR: The name is necessary for the activation of the product".)

NILicensingCmd#exe /silent /activateall /serialnumber <my serial number>

Adding the silent flag prevented the message (as expected) and also the popup (not explicit in the description), so perhaps this is the required call?

Using the GUI for NILM to deactivate LabVIEW 2021 (and a few, but not all modules) , closing the GUI, and then running the same command, and then reopening the GUI shows LabVIEW 2021 as "Unlicensed", which I guess means it didn't work?

I'm currently trying a few variations on the single /activate option, but the documentation here: ni-license-manager/21.0/manual/automate-activation makes it look like I might struggle in the case that I'm not logged in already, e.g. in a Docker container (but testing will tell, I suppose).

.\NILicensingCmd#exe /silent /activate /type package /name "LabVIEW_PDS_PKG" /version 21.0000 /serialnumber <yay serial>

This command successfully activated LabVIEW Prof. Dev System, and seemingly did so without popping up any windows. I was, however, already previously logged in to NI-Auth.

I'll test it in Docker and post again, hopefully soon(ish, read days not hours but hopefully not weeks...)

[felipefoz]

---

@EricR wrote:

Having said that, this is an area I would love to have feedback on.  We have been evaluating multiple different approaches to these CI/CD workflows and I'm actively working on modifying our current approach.  I'd love to know what other tools you are using on those CI/CD workflows and how they interact with VM images.

---

I've been for a while running successfully some pipelines with docker images, not very complicated pipelines (like FPGA, RT), with simple images that allowed me to run Unit Tests, VI Analyzer, perform some builds, etc...

Here are some examples:

https://gitlab.com/felipe_public/gitlab-tools-labview/build-cli-operation/-/pipelines/276011891

https://gitlab.com/felipe_public/labview-shared-libraries/broker_af/broker/-/pipelines/279521632

I am already trying to foment this idea of Docker images through this Idea Exchange Post, any new kudos would help it out, wouldn't it?

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Official-LabVIEW-Docker-Images/idi-p/4158952

I already have some "recipes" for building the most common LabVIEW images, which work, but, it could use some optimization from NI, especially in shrinking size.

https://gitlab.com/felipe_public/labview-docker-files

About licensing, after reading Christian's post apparently nothing has changed since LV 2020. In my case, the only feasible way was using NI VLM Server with named or on-demand licenses, but this has a limitation for some people because it requires at least 5 licenses to allow this kind of management.

Anyhow, I am also available to help in any improvements, feel free to contact me @EricR.

[cbutcher]

Initial attempts with /silent /activate in Docker were unsuccessful. Will keep trying but not a great start... Maybe some different combination of package and family options?

[JeKo]

We use:
"C:\Program Files (x86)\National Instruments\Shared\License Manager\Bin\nilmUtil.exe" -s -activate "$productcode" -serialnumber "$serial" -firstname "$first_name" -lastname "$last_name" -organizationname "$org"

where $productcode is a code like:
"LabVIEW_PDS_PKG 17.0001" or "LabVIEW_FPGA_PKG 17.0001"
I didn't find a good list of the product codes, I read them from the license files on disk.

[cbutcher]

---

@JeKo wrote:

We use:
"C:\Program Files (x86)\National Instruments\Shared\License Manager\Bin\nilmUtil.exe" -s -activate "$productcode" -serialnumber "$serial" -firstname "$first_name" -lastname "$last_name" -organizationname "$org"

where $productcode is a code like:
"LabVIEW_PDS_PKG 17.0001" or "LabVIEW_FPGA_PKG 17.0001"
I didn't find a good list of the product codes, I read them from the license files on disk.

---

I couldn't quite make this work at first, but either it worked and I was impatient, or it worked changing the product code to "LabVIEW_PDS_PKG" and adding -version "21.0000". 

In any case, this looks good and seems to have worked. A quick check with G-CLI looks promising.