Continuous Integration
Information re LabVIEW (2021) in Docker containers
So I'm going to start a thread to post what I'm learning, and wanted to stop derailing this thread: LabVIEW-Continuous-Integration-License.
Hopefully the contents of that thread indicate that it should be more possible to build your own container and license it without a service request, even without VLM, but I haven't yet confirmed that for myself (and Felipe makes it sound unlikely, although maybe he was misunderstanding what I'd written).
My first enjoyable finding is that "nipkg pack" now works in windows/servercore:2004. I don't know if something changed in NIPM 21.0.0 (or potentially a couple of previous versions, I last tried with 20.5 in windows:1909), or if this is due to some update in the Microsoft images, but this is very useful for writing a Dockerfile that can create its own fake packages.
A list of packages (not updated for 2021) that I faked previously, for the cRIO build demo at GLA Summit, is as follows:
ni-cabled-pcie
ni-controllerdriver
ni-ede
ni-pxiplatformservices-runtime
ni-rio-fpga-driver
ni-rio-mite
ni-serial-runtime
ni-usblan
ni-usbvcp
ni-visa-shared-components
I'll check through and see if any of these became more installable without fakes, but if not, they can now be easily recreated. It's possible that other packages might also need to be faked, depending on what you're trying to install in the end...
Something to note in this endeavour is that not all packages have a version 21.*, presumably due to varying update cycles for different drivers. So pattern matching on version 21.* using nipkg info can be a problem (for example, it seems like version 19.0.0.49153-0+f1 is the latest ni-usblan).
The feeds I'm currently using for 2021 are generated as follows:
# This script adds feeds to nipkg for a specific build set
# Here we focus on LabVIEW 2021, 32-bit.
$year = "2021"
$pkg_root = "https://download.ni.com/support/nipkg/products"
$lv_modules = "rt-module", "fpga-module", "vi-analyzer-toolkit", "aspt-toolkit", "cdsim-module", "mathscript-module"
# The "core" modules don't include core in the URL
nipkg.exe feed-add --name="""ni-labview-$year-core-x86-en-$year-released""" --system $("$pkg_root/ni-l/ni-labview-$year-x86/21.0/released")
nipkg.exe feed-add --name="""ni-labview-$year-core-x86-en-$year-released-critical""" --system $("$pkg_root/ni-l/ni-labview-$year-x86/21.0/released-critical")
# The other ni-l/ni-labview-... packages have a shared pattern
ForEach($module in $lv_modules)
{
nipkg.exe feed-add --name="""ni-labview-$year-$module-x86-en-$year-released""" --system $("$pkg_root/ni-l/ni-labview-$year-$module-x86/21.0/released")
nipkg.exe feed-add --name="""ni-labview-$year-$module-x86-en-$year-released-critical""" --system $("$pkg_root/ni-l/ni-labview-$year-$module-x86/21.0/released-critical")
}
$feeds = @(
[pscustomobject]@{name = "ni-daqmx-21-0-released"; url = "$($pkg_root)/ni-d/ni-daqmx/21.0/released"}
[pscustomobject]@{name = "ni-visa-21-0-released"; url = "$($pkg_root)/ni-v/ni-visa/21.0/released"}
[pscustomobject]@{name = "ni-compactrio-21-0-released"; url = "$($pkg_root)/ni-c/ni-compactrio/21.0/released"}
)
ForEach($pair in $feeds)
{
nipkg.exe feed-add --name="""$($pair.name)""" --system $($pair.url)
nipkg.exe feed-add --name="""$($pair.name)-critical""" --system $($pair.url + "-critical")
}
You can see the names of the main modules in the "$lv_modules" variable, there is also the "core" feed and each has a -critical version too (although I don't know if these matter for Docker so much...)
DAQmx, VISA and CompactRIO have a slightly different naming pattern, so they're handled separately at the bottom of that script, which I copy into my container and then run to add the feeds.
As can be seen, nipkg is on my PATH to be able to run these more easily.
JeKo wrote the following in the previously linked thread:
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.
Either that or $productcode -> "LabVIEW_PDS_PKG" and -version "21.0000" worked for me.
Given the version numbers in their post, I wonder if this was a working strategy in previous versions? 😮
A quick check with G-CLI's built-in operations, "quitLabVIEW" and "Echo" (with -- "Hello World" as a test) seems to suggest this is now working without a support request! 😄 😄 😄
Of course, this still required copying in G-CLI following the instructions given in Chris Stryker's blog post here: http://stry.kr/2020/06/09/contain-your-excitement/
but it's pretty nice stuff.
More detailed tests coming soon, and then I'll work on a proper Dockerfile (combining the obvious installation blah blah with the package faking, since nipkg pack can now work in a Docker container), and some examples for using this to build cRIO applications and cross-platform PPLs, as well as DAQmx-dependent exes.
@cbutcher wrote:
Hopefully the contents of that thread indicate that it should be more possible to build your own container and license it without a service request, even without VLM, but I haven't yet confirmed that for myself (and Felipe makes it sound unlikely, although maybe he was misunderstanding what I'd written).
Yes Christian, you are right, I tried all possible ways with License Manager by itself in the 2020 version, haven't tried with 2021.
@cbutcher wrote:
I'll check through and see if any of these became more installable without fakes, but if not, they can now be easily recreated. It's possible that other packages might also need to be faked, depending on what you're trying to install in the end...
For installing the fake ones I built the packages in batch using the NI Package Builder, which I end up installing at first together with the NI Package Manager. At the end, some of my builds didn't work using the RT and I eventually gave up improving this method.
@cbutcher wrote:
A quick check with G-CLI's built-in operations, "quitLabVIEW" and "Echo" (with -- "Hello World" as a test) seems to suggest this is now working without a support request! 😄 😄 😄
Of course, this still required copying in G-CLI following the instructions given in Chris Stryker's blog post here: http://stry.kr/2020/06/09/contain-your-excitement/
but it's pretty nice stuff.
Well done, that is indeed great news. Maybe we can use for the Community Edition??? Maybe it is a long shot, but let's have some hope there.
Managed to build my GLA Summit 2020 RT application and also build (in the container) and run (in the host) a previous DAQmx test exe.
This process was somewhat interactively carried out, since it's faster than constantly adjusting and rebuilding Dockerfiles, but there's no reason it can't be placed in a Dockerfile.
So looks like we can do this now* without support requests for activation or any changes from NI, although installing enough of DAQmx to get it building is still a bit of a pita... 😞 (I also didn't test 64-bit DAQmx yet).
*: Perhaps this has been possible for years with JeKo's command line... go figure.
@felipefoz wrote:For installing the fake ones I built the packages in batch using the NI Package Builder, which I end up installing at first together with the NI Package Manager. At the end, some of my builds didn't work using the RT and I eventually gave up improving this method.
Can you give a bit more detail about how "some of [your] builds didn't work using the RT"? (Also, is that 'Real-Time' module, or 'Run-Time' as in exes?)
@cbutcher wrote:
@felipefoz wrote:For installing the fake ones I built the packages in batch using the NI Package Builder, which I end up installing at first together with the NI Package Manager. At the end, some of my builds didn't work using the RT and I eventually gave up improving this method.
Can you give a bit more detail about how "some of [your] builds didn't work using the RT"? (Also, is that 'Real-Time' module, or 'Run-Time' as in exes?)
(Real Time Module) Honestly, I don't really remember as I didn't try harder. But my guess would be that had something to do with NI Modbus API or NI CANOpen Module, but I would bet on the last one.
The scanning script looks quite interesting, I'm going to look through it some more, but it looks like you're having some problems due to spaces in the feed names.
The script is (if I'm reading it correctly) splitting the results of `nipkg feed-list` by the space character, but some feeds (e.g. "ni-labview-2019-runtime-engine-x86-2019 SP1-released") contain spaces.
That was the only NI feed that I found on this computer with a space, but I suspect there may be more - perhaps one is breaking your script.
At least in my quick testing, you'd have better luck using
foreach ($item in $FeedBall) {
$NU = $item -split '\t'rather than '\s'.
In my case I chose to explicitly list which feeds I wanted, since I felt that would make the collection clearer, but of course your FeedsInstall.json file could be version-controlled, etc.
