Continuous Integration

cancel
Showing results for 
Search instead for 
Did you mean: 

Command Line Tools for Continuous Integration

Hello fellow CI enthusiasts,

 

A while ago with the hope of making CI easier with LabVIEW I put together a toolkit for using a command line interface with LabVIEW programs so that it is easy to use Jenkins and other CI tools.

 

A few people have run with this and it is now on the tools network and there were several presentations of it on at NI Week (see https://forums.ni.com/t5/Continuous-Integration/NIWeek-2017-Automated-Test-of-LabVIEW-FPGA-Code-CI-a... for an example!)

 

What has been interesting to me is that I had intended to take this and create a build tool where you have a configuration file to define the different builds or tests you want to complete.

However those that have used it have tended to make smaller tools for each task for example the presentation linked above or the DCAF project on github which has created the CLI common steps package on the tools network.

 

So the discussions I had with various people agreed that it is worth combining our energy towards a single set of tools. The question I have for you all is. Would you be most interested in:

 

1. A series of VIs you can call for each function. Right now it means that you need to close and open LabVIEW for each step but each step is very simple and can be chained as stages of a Jenkins pipeline.

2. A LabVIEW "build" tool which takes a configuration file so you can just call LabVIEW Build from the command line but it is likely to be somewhat more complex.

 

What would you be interested in? What do you do now?

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 1 of 30
(12,516 Views)

Since I'm the one who wrote the collection of simple steps referenced above, I am in favor of keeping the tooling as dumb and transparent as possible, and leave the build orchestration to Jenkins.

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 2 of 30
(12,515 Views)

I am in favour of the option that is easiest to support, maintain and extend. We have our own in-house test framework for example, and we don't use Jenkins (TeamCity) and thus have our own suite of plug-ins to support the CI API.

0 Kudos
Message 3 of 30
(12,508 Views)

Thanks Matt! I was struggling to find a web link to the tools - are they on github somewhere?

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 4 of 30
(12,504 Views)

https://github.com/LabVIEW-DCAF/buildsystem/releases

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 5 of 30
(12,501 Views)

I use Gitlab's Continuous Integration & Deployment Pipelines instead of Jenkins, but both offer similar extended functionality for configuring and executing build jobs.

 

In gitlab, you configure the CI and CD jobs in a very straight-forward way by means of a text file (the .gitlab-ci.yml file) that's part of the repository itself. The file defines a set of jobs  (scripts to be run) with constraints stating when they should be run. The scenarios can be as simple or complex as you need them to be, based on a per-repository basis. 

 

I came up with a set of VIs, each for one purpose (eg setup, analyze, test, build, package, deploy), as I felt it serves the mechanisms of the CI/CD tool much better, and it's very easy to call them one by one per stage. Combining them is then the job of the CI pipelines. I also do have a little application that lets me configure and execute the whole build job locally.

 

Hence, I'd be interested in the "series of VIs" option.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 6 of 30
(12,488 Views)

That's really interesting Joerg, the main thing that made me think of the other tool was the ability to run it locally as well. So is that a LabVIEW app or something else? I know someone at CLA-E was using make files for this

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 7 of 30
(12,470 Views)

It's a LabVIEW app actually.

 

Back when I called my build tools only manually, I used to have all functionality inside one VI, my "AppBuilder". I would read the project file I wanted to process, and have a proprietary config file in the same directory.

 

When I started with the gitlab CI and calling the build tool from the Gitlab runner, I shelled out the functionality of the different stages into single VIs to call them one by one from the Gitlab runner. I kept the GUI, and the AppBuilder now calls the VIs - just as the Gitlab Runner does - from the command line with your CLI-LabVIEW tool.

 

I'll be happy to share the code with you if you're interested, but it definitely needs a little more love before I can show it to you or even in public.

 

hse_appbuilder.png




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


0 Kudos
Message 8 of 30
(12,462 Views)

Wow that looks fantastic! (no need to share, just the inspiration is great).

 

I think that kind of answers my question then that for the CI side having several independent tools seems to be the preferred option, especially if you original had the all in one and deliberately moved away (but if your lurking do chime in if you think the opposite)

 

By now I should have Matt's tools installed so I can try them out. Thanks for the web link for those although the github repo seems out of date?

James Mc
========
CLA and cRIO Fanatic
My writings on LabVIEW Development are at devs.wiresmithtech.com
0 Kudos
Message 9 of 30
(12,448 Views)

Github release is one version ahead of what is posted on tools network.  It will be bumped over to tools network once your latest version (integrating the MSI) is posted, so I can simplify the instructions on my set.

 

I'd also be very happy to have you roll in those pieces to your tool set and deprecate mine entirely.

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 10 of 30
(12,442 Views)