Continuous Integration
LabVIEW Continuous Integration License?
Eric,
I'm not sure how feasible this is, but in my mind the ultimate solution would be for NI to maintain of set LabVIEW Docker images. You just pull one and spin it up as needed. Somehow just limit access to people with a current SSP, or maybe some additional addon that cost a few extra bucks.
Sam
I agree the install would kill one of the main advantages of CI which is rapid feedback.
A Docker Image or Vagrant Box with LabVIEW preinstalled would solve a lot of that. You still might have to install a few addons, but you could build your own Docker with the LabVIEW one as the base. That would be a one-time hit.
@joerg.hampel wrote:
* We’re not really „integrating continuously“ (although we use the GitLab CI engine, Jenkins or Azure Pipelines to trigger automated processes) and I bet most people here don’t either. Or do you?
I certainly try to. I can't say that I succeed on every project. Although can you really call it CI if you are a one man shop? Who am I integrating my changes with? myself?
@joerg.hampel wrote:
For how we and our customers use server-side automation*, installing LabVIEW for each pipeline (or even for each job) doesn’t sound feasible. If it’s more or less a regular LV install process, that would take way too much time I think. We‘re already looking at ways to streamline processes like VI Analyzer or generation of documentation. Adding a full installation would be just the opposite.
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.
Then when you run the image/VM/container/blob-file-on-disk, you'd activate the license as part of the process (and presumably then deactivate it after finishing).
My hopeful reading of this is that it will simplify the relationship between (number of VMs/containers) and (number of licenses) when containers/VMs/images are not in continuous use...
If we get really lucky(?), then it might make it so we can license containers (not images, here describing Docker but similar ideas probably apply elsewhere) as we use them, and that will (perhaps?) remove some of the difficulties when taking an image created on one machine (e.g. developer PC, maybe using a different host license) and creating containers from it on another (e.g. build machine, maybe using the CI license - although my CI runs with a dev license).
@joerg.hampel wrote:
* We’re not really „integrating continuously“ (although we use the GitLab CI engine, Jenkins or Azure Pipelines to trigger automated processes) and I bet most people here don’t either. Or do you?
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.
If I can (find time to, and then succeed at) implement these build processes instead in Docker containers (currently they run on the VM running the Jenkins instance, i.e. the root/master node) then I will presumably cut build times significantly (because I can run debug/release and Win32/64+cRIO in parallel, a 6x improvement in an ideal case, although some steps would need to be duplicated in each case (cloning repos, etc) so it wouldn't be quite that good...)
The stumbling block isn't actually with NI - although an easier time creating/managing/licensing images and containers would certainly help - for me my issues are rather more mundane and relate to nested virtualization being unavailable on my current host... I also want to move to NIPKGs perhaps but there are a few details I haven't made my mind up about and I had hoped that I could rearrange things to improve debugging PPLs on cRIO, but apparently that's a "wont-fix" bug.
@EricR wrote:
If you show me how to get Docker to install DRIVERS as well, I'm all in on providing Docker Images as an alternative installation. I'd love to do a whole brainstorming on just that one topic because I really love the workflow of a basically-zero-install for all kinds of software. I just can't get the virtualizing "layers" that exist today to handle all of the software I need for a good T&M application. There is always some part that they want me to just include in the base install layer.
Do you want the drivers to work? As in, do you want your actual T&M application to run from a Docker container? Or are you instead wanting to build something (perhaps exe) in a Docker container that uses the drivers (e.g. DAQmx)?
I demoed using Docker to build an application for cRIO at last year's GLA summit, if the latter (including running it successfully on actual hardware), and separately I believe I had installable DAQmx builds, although my demo didn't include any DAQmx code...
For the former, I'm not so sure - but I think NI/you could perhaps make it possible... If you DM me or send an email, I can give you more information about the specific nipkg files that I had problems with installing inside a Docker container - you might be able to indicate if you believe these are true blockers or not...
@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.
I'm hopeful that this is great news. Will it work with all licenses? (I believe VLMs already had an easier time with Docker...)
What are the restrictions? (Or will this information be part of NI-Connect and not yet publicly shared?)
