Denver - ALARM
July 17, 2025 Meeting
|
Here is a summary of my presentation - the slides aren't all that interesting, so I skipped those and just did a tldr.
All about quick feed back and moving quickly from please to thank you.
Individual Steps you might want to automate:
- installing dependencies (of all kinds)
- running unit tests (and other types of tests)
- building (exes, installers, vipm and nipm packages, zip files, source distributions, docker images)
- generating documentation (maybe SBOMs, AntiDoc, maybe requirements coverage matrices, etc.)
- VI analyzer and other linting/code checks
- uploading artifacts - exes, documentation
- notifying either yourself or customers - sending e-mails, texts, etc.
- installing your software (and maybe testing it again afterwards).
Progression of how to automate in order of complexity/power:
- Manual build process - if you are here, at least document it. Readme is a good place for that. It's a good first step.
- Pre/Post build VIs - maybe run tests first and or install needed dependencies. An error out stops the build. Can upload things after build.
- One-click build (LV VI) - perhaps chaining multiple builds (using LV's Build API), like build exe then build installer.
- Bash/Powershell Build script along with G-CLI or LabVIEW-CLI - can use built-in VIs, custom VIs or sas-gcli-tools. Let's you chain a bunch of things together, acts as documentation of your process.
- Git Hooks - I missed talking about this, but once you have a script you can easily run it as a git hook locally. Examples: Check commit message to make sure it includes a Jira Ticket number, run unit tests (must pass before accepting commit), run VI analyzer tests before pushing commits. This is very useful to help prevent pushing stuff that breaks on the server.
- full on GitLab/GitHub CI/CD - Complicated. Lots of moving parts. Requires setting up runners. Super powerful. Lots of workflows available.
When it comes to scripts, I recommend putting variables in a separate file so you can reuse the scripts. - see the template, blue, or approvals as examples. If you do full-on CI/CD I recommend each job simply calls a script and push the complexity into the script. Makes it easy to run the script locally for debugging.
Resources:
https://sas-gcli-tools.gitlab.io
template:
https://gitlab.com/sas-gcli-tools/vipm-package-ci-example
https://gitlab.com/sas-blue/blue
real world examples:
https://github.com/approvals/ApprovalTests.LabVIEW
Also if anyone is interested - here is my CI/CD video course. It is on sale at the moment. We also do a 2 day CI/CD workshop which is more interactive where I am there to help you troubleshoot everything and make sure it works. If that is of interest, just reach out.
https://sasworkshops.thinkific.com/courses/ci-cd
Some of you might also find this article useful.
https://blog.sasworkshops.com/what-is-the-value-proposition-of-ci-cd/
