LabVIEW + Docker + Windows = Match?

The last few weeks I’ve been busy, I mean, really busy trying to figure out how to assemble everything together, and I finally got something to work. After all, is LabVIEW + Docker + Windows, a match?

Continuous Integration

During my mission of implementing Continuous Integration in my development workflow it wasn’t clear until so far what kind of approach I would take. After reading a little bit, I came to the conclusion that Virtual Machines would be an obvious path, because everything else would be a partial solution, in example, running a CI on your machine.

Virtual Machines are a good solution, but they have some problems, like licensing every copy of Windows and replicability, every time you run a test, you take the risk of leaving residues that can influence further tests.

Studying Continuous Integration, specifically Gitlab CI Tool Chain. I got amazed of how easy was to implement the CI in some languages and I wondered, why is not that easy in LabVIEW?

By the way, continuous integration is definitely not only about automating your development, it is really a philosophy of software development with many steps (more on that in a future post).

Docker, yes, you can

So, not long ago, I stumbled with a post in Christopher Stryker blog, where he was explaining how to create an image using LabVIEW. Really, in the first time I didn’t take it seriously, because, I had already read before about these attempts, and none of them end up in anything productive, but maybe this time.

This was definitely reinforced when I also read in Sam’s Blog about this achievement, and in our virtual “coffee” we got some discussions about it, and the repository from rdecarreau came up, and I said “Aha, maybe I can do it”, why not?

This seemed a valid point for me, because, as I was already in stage of setting up the continuous integration environment, why not trying a solution that is already used successfully by other programming languages.

Learning Docker

Definitely, that was the toughest part of the road. I had used Docker before, but in my use cases I pulled only images and started using, I didn’t need to learn anything about how images are made, layers, docker files, docker commits, pushes, how they are stored.

Yes, all that points were needed to implement the CI with docker. There is not many things done in this area with LabVIEW, so we need to grab what we already have and work with it.

After a lot of effort, I came up with these docker files, which I stored in my Gitlab Repo. Some of them work out of the box, and some of them needs some tweaking.

LabVIEW Docker Files Repos

In base with these docker files, I created some images to be used in the Gitlab CI Runner. The images needed to be pushed to docker hub in order to work with the Runner, so I created some repositories there to store it. Then, you can check it out if you want.

felipefoz Dockerhub Repositories

I organized in a way that I could split the docker images in layers, then I can switch the upper layers (toolkits) very easily and create new images (more on that in a future post).

Licensing

After everything done, I thought I could go easily through this step. The images above are not licensed yet, so they are useless until you license your LabVIEW copy.

Licensing a container is still a pain. I couldn’t find a global solution that every developer could implement. I tried Serial Number, different licensing app versions, everything in my power, I also contacted the Brazilian TSE to help me out, but unfortunately the generated licenses did not work.

The problem lies in the container, with constant changing of the computer name (hash), which can mess up with the entire licensing process.

The solution was in front of me. Here we manage our licenses in the network with a VLM. After trying to insert using a computer profile and failing, I tried to create a user for docker and voilá, it worked. Now, all I needed is to add the VLM Licensing before every run. The sample code in gitlab-ci.yml is something like that.

.default:
  tags:
    - labview
  before_script:
    - NILicensingCmd.exe /silent /addservers $LICENSE

VI Analyzer:
  extends: .default
  stage: code quality
  image: felipefoz/vianalyzer:20.0

Unit Testing:
  extends: .default
  stage: test
  image: felipefoz/caraya:1.0.2-20.0

The result is the pipeline shown below.

As you noticed with the results from the tests I can see on the web if some of them failed, such as VI Analyzer Tests, and other interesting feedback from the runner, if I decide to optimize the pipeline.

About that, there is still some obscurity behind VI Analyzer Tests, because none of them failed in my machine, but that I’ll leave that for further research.

Caveats and Next Steps

I’ll probably extend my pipeline by implementing steps of building, tagging and releasing, but that is part of the continuous learning in the continuous integration.

The licensing solution may not work for everyone, but I believe NI might be already working on an easier solution for command line licensing, because everything else seems to work fine so far.

I also did not install VI Package Manager (VIPM), because I read that people were having trouble and in my case I don’t use for deploying my applications, only for development. The exception was JKI Caraya, which I needed for my Unit Testing. In that case, I extracted the files, mass compiled them and put inside the docker image to get it working.

Hopefully, we will continue to improve in this area, and maybe some day we will already have NI Docker Official/Verified Images to use in our CI projects.

Aknowledgments

• To my colleague Marcos Balsamo that helped me with Docker.
• To the Brazilian NI TSE F. Flores that helped me with the licensing.
• To the LV Developers, Chris Stryker, RdeCarreau and Sam Taggart that keep helping everyone by spreading their knowledge to the community.