Setting up a simple device CI/CD pipeline for your project: part II

In this series of posts, we propose a simple and full open source CI/CD pipeline for your Linux device development on GitLab that takes advantage of the power of Pantahub and Pantavisor.

Table of Contents (4 part series)
Part I: keep devices up to date
Part II: generate flashable images
Part III: template internals
Part IV: pipeline customization

In the previous post, we went through the basic setup to keep a couple of devices automatically up to date with the latest and stable versions of your project’s code base.

In the second part, we are going to continue where we left it and add to the pipeline the ability to generate and store flashable images with the stable version of your project.


Now, we can keep a bunch of devices up to date with the latest and stable version of our software. That will help us with development, as we are going to have always access to test and manipulate those devices with the security that they will contain those versions of our code.

An immediate need after testing a working version could be replication. For devices with Pantavisor already installed, you can just remotely update them but, can we spread this to new devices when the need to prepare the hardware for production arises?

Our CI will help you with this, and it will allow you to keep a list of stable factory images that you can use to flash devices with your ready-to-use software.

Set up the AWS bucket

We are going to use AWS to store the flashable images. You can register for a free trial here.

After this, you will need to create a bucket to store the images in. You will also need an IAM user, set writing permissions on the bucket for that user and create an access key to be able to upload the images from device-ci.

Set up the GitLab project

The pipeline will take the AWS credentials created in the previous section from a group of variables we must set. These are AWS_BUCKET, AWS_PROJECT_PATH, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. You will have to set them as GitLab CI variables in your device-ci project. Don’t forget to mask AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY!

Test it

First step will be selecting the commit we want to tag from the ci project we created in the previous part of the tutorial. In device-ci, each commit corresponds to a different state of the device.

In this case, we can physically see that latest device (at the right) is working as desired for our next stable version, which will include the LED blinking feature from part I.

Latest version corresponds with the latest commit in our GitLab project if the pipeline finished without errors. So we will tag that one with the name 001.

In the git log, we can check if the changes contained in the commit we just tagged are good and match with the version of the device we want to release. After that, we push the tag.

You can see the stable job has already begun after the push in GitLab.

The pipeline has successfully updated the stable device (at the left) with the version that corresponds to the tagged commit!

After the post, our CI will check if the upgrade went well with a verify job that will trigger an error in case the new version breaks the board boot up process.

Let’s check the pipeline has passed and the image has been uploaded to AWS in GitLab CI log.

The updated stable device name, revision , generated image download link and other relevant metadata can be consulted in a json at the root of your project path in AWS.

The URL to that AWS will vary depending on the values of the variables you set in the configuration section.


In our case, the json containing the metadata for the example we prepared for this post is:

What’s next?

In the last part of the series, we are going to explore the internals of our templates. Also, we will explode this knowledge to override the jobs to make the pipeline fully customizable.