How many clicks does it take you from saving your VI to getting your built application to your customer?
Quite a lot, probably. That’s what motivated us to look into automating some of our build steps. Today, our automation chain covers most of the important scripts in our release process.
Available Build Scripts
1. Changes are pushed to Source Control Server
Gitflow dictates the way we create and merge branches in our repos, and when and where we create releases. Hence, it also defines the calling points of our automation.
Whenever a developer pushes back to the master repo (the origin), the GitLab CI/CD automation mechanism is triggered and executes according to its configuration.
Watch a screencast of this at youtu.be/ue0NeYNEYf0.
2. Source Control Server triggers Build Server
The .gitlab-ci.yml configuration file, which is part of the repo and therefore project-specific, defines which actions to take on which event („when to call which scripts“).
In order to execute actions on a build server, the GitLab Runner has to be installed on the build server. It is called from the GitLab CI and executes the actions defined in the .gitlab-ci.yml file.
On our system, the runner is called whenever a tag is pushed.
Watch a screencast of this at youtu.be/1MGP5X-LmYE.
3. Build Server executes Tools
The runner executes the scripts defined in the .gitlab-ci.yml file: Our Release Automation Tools. These tools are a collection of custom-built LabVIEW VIs that do the actual work: Testing, building, packaging and deploying our LabVIEW projects.
The VIs are built on JKI State Machines for macro functionality, and they are executed by the runner via Wiresmith Technology’s G-CLI tool, which allows to output data to the command line – and feed back to GitLab – while the VI is still running.
Watch a screencast of this at youtu.be/FTYpQNPgwAQ.
4. Built files are published
The last step in the build chain is taking the build results and moving them to a networked location (a NAS) that is accessible from the public web.
We use Dokuwiki to serve build results on the web. Our proprietary Dokuwiki plugin queries the GitLab API for the project’s tags. Based on the tag list, it queries the file server for files related to each tag and auto-generates the download links on the release webpage.
Watch a screencast of this at youtu.be/POB25NRlxD4.
Are you interested?
Please download the presentations to learn more about our setup. Contact us directly if you want our help building a similar system, or if you’re interested in using our Release Automation Tools on your own servers, or if you just want to chat about automation and CI/CD.