Challenges

Let's say a company is already using the TargetLink Automation Package to continuously build and test production code before those artifacts are approved. Infrastructure engineers have set up an automation server, for example, Jenkins, that is one of the widely used automation servers. Developers commit their changes to a Git repository and the agents start building and testing the committed changes. At first glance, this seems like a perfect world. However, developers face the challenge of committing every change, no matter how small, to wait for feedback from the Jenkins pipeline. The inability to test changes in advance can waste time and resources if the pipeline fails and an additional iteration is required. At dSPACE, we faced similar challenges, for example, when developing TargetLink or other Linux-based products, so we set out to find solutions for ourselves and thus for workflows at customer’s site.

Challenge Accepted

To meet this challenge, the first thing that comes to mind is a virtual machine running an instance of the TargetLink Automation Package under Linux. However, this approach works but has a number of drawbacks. Typically, virtual machines reside in the cloud or on-premises, so data transfer and resources are an additional overhead when using virtual machines. However, there is another solution, which meant we did not have to reinvent the wheel. The Windows Subsystem for Linux (WSL) allows the user to run a Linux environment directly on Windows without the drawbacks of traditional virtual machines.

Hello WSL

It would be beyond the scope of this article to talk about all the features of WSL, but we would like to mention at least the most important ones from our point of view:

• WSL is installed by default in Windows 10 and 11, does not require a third-party application, and has no additional costs.
• WSL is customizable. You can choose which Linux distribution you want to use and customize it to your needs. Even a hardened Ubuntu® image is an option.
• WSL is reproducible. Once you configure a Linux image, you can deploy it across the organization.
• WSL is fast and uses relatively few resources.
• WSL lets you work with your Windows file system. This means you can access the Git repositories you are working on.

Assuming MATLAB® is already installed in the WSL, installing the TargetLink Automation Package is the same as on any other Linux system, and we have covered this in the user documentation. But what would a typical workflow look like to ensure a seamless transition from interactive development with TargetLink to continuous integration and testing with TargetLink?
 

TargetLink for Automation WSL Workflow

Once changes to a model have been made and saved to the cloned, i.e., local, Git repository, you can use the configured WSL to test your changes before committing them. We recommend using the Windows Terminal application, a free-of-charge host application for multiple command-line shells, which can be installed via the Microsoft Store. Simply open the Windows Terminal application and launch an instance of your WSL. As soon as the WSL starts, you are ready to access your cloned Git repositories. The WSL will automatically mount all your internal drives under /mnt (Figure 1).

You can then navigate to your Git repository, run MATLAB or any MATLAB script, and test your changes as needed (Figure 2).

As you can see, the transition between your interactive development in TargetLink on Windows and the TargetLink Automation Package is seamless when using WSL. Once you have tested your changes, you can commit them to the Git repository and create a pull request. Then the automation server will start building and testing the production code.

Learnings from the Stoics

The Stoics have long known that change is inevitable and that the only thing you can control is how you deal with change. The continuous processes of development, integration, and testing to produce more software of higher quality in shorter development cycles is one such inevitable change. At dSPACE, we are committed to addressing the challenges of this change for our customers and to finding ways to integrate model-based development into continuous processes. In this blog post, we have shown how developers can make the transition from interactive development on Windows to the TargetLink Automation Package under Linux as smooth as possible, so that their development process can adapt well to the changes and be taken to the next level. If you have any questions on TargetLink on Linux or WSL, feel free to contact us.