CI/CD with Qlik Sense, GitHub Actions and self-hosted runners

In spite of Qlik Sense having great APIs, little has over the years been done around continuous integration/deployment (CI/CD) of Sense apps.

It’s not that CI/CD is a bad idea – rather the opposite. These days it’s probably the closest thing to a standard way-of-working there is.

I wrote about this topic some years ago, focusing on using Jenkins with Qlik Sense.
Lot’s has happened since then…

GitHub Actions

Today GitHub offers their “GitHub Actions” concept on all GitHub tiers (free, paid, private, public). You can even spin up GitHub runners in your local network and configure them to accept GitHub Action workloads from a github.com repository.
This opens up some rather interesting opportunities when it comes to doing CI/CD (and other things) with Qlik Sense.

The video shows how a change in a .qvs script file is checked into a Git repository, then automatically loaded into a Sense app without any manual intervention except the initial commit/push of the change.

The Butler open source toolbox provides the API for starting the app reload in the Sense server.

The reason for using a self-hosted GitHub runner is that we don’t need to open any firewalls into our network. The local runner will poll github.com to see if there is any pending work awaiting. When there is, the runner will accept and execute the workflow.

GitHub Actions: Cloud vs local runners

GitHub Actions fundamentally builds on the concept of runners, with a runner being a process that carries out the steps defined in the workflow file(s) that are stored in the GitHub repository. There can be many different workflow files, each carrying out some task.

There can also be more than one runner. You may for example want to test your software on both Linux and Windows – you’d then define two different runners. One for each OS.

Another distinction is where the runner executes: Within the GitHub cloud service or as a local/on-premise service.

Using cloud runners is very convenient (no need to install any software on-premise), but if your workflow involves interacting with on-premise resources things can get tricky. You probably need to open up your firewall(s) for incoming traffic from the GitHub hosted runners. While certainly possible it’s usually a good idea to keep firewalls as locked-down as possible.

The other option is to use self-hosted runners.
These run in your own network, close to (=with network access to) your Sense environment. The runners are configured to check in with GitHub a few times per minute and then execute any pending workloads.

The advantage with self-hosted runners is that you don’t need to punch holes in your firewalls. On the other hand you must trust the self-hosted runner as such:

Who do you trust?

Those of us that are a bit paranoid would point out that we’re downloading and executing a payload into our own, on-premise server environment.
A true and valid comment – what’s shown in this video assumes you trust the contents of the GitHub workflow, that GitHub knows how to keep secrets etc.
If you do trust that, this CI/CD model is however both elegant, easy to set up and very powerful.