# GitLab runner on balena devices for continuous integration testing **URL:** \ **Category:** Project help\ **Tags:** gitlab\ **Created:** [January 25, 2019, 8:22pm UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090 "2019-01-25T20:22:56Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![imrehg](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/imrehg/32/36_2.png) [@imrehg](https://forums.balena.io/u/imrehg)\ **Post date:** [January 25, 2019, 8:22pm UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090/1 "2019-01-25T20:22:56Z")
Here’s a project I wanted to share with you. I’m very much interested in automation, and recently was playing with the continuous integration/continuous delivery (CI/.CD) tools that [GitLab](https://gitlab.com/) provides. Their platform allows you to add your own “runners”, devices that are running the testing/building/deployment jobs. Inspired by that, I wanted to create an easy way to add balena devices as runners to GitLab (either the platform or your own open source GitLab installation). The result is the following project: > **[balena-io-playground/balena-gitlab-runner](https://github.com/balena-io-playground/balena-gitlab-runner/)** > > Gitlab Runner as a balena application. Contribute to balena-io-playground/balena-gitlab-runner development by creating an account on GitHub. What it does: - the `gitlab-runner` for a given platform - you only have to supply the GitLab runner token to register it, otherwise it is set up with good default values, that you can also change - it registers your runner to GitLab, adds device type, architecture labels to your runner (so e.g. you can say "I want this job to be run on a `raspberrypi3`", or “… on an `armv7l` device”) - the runner is using the onboard docker/balenaEngine, and has an added garbage collector, so that the docker images are not going to fill up your device, hopefully - after the first automatic registration you can use `gitlab-runner` in the container to register the device to more than one projects (or use the GitLab dashboard to assign a runner to multiple projects) To try it out, you can do the following: Create a new balena application, and push the above project to it. Then take a device you have, and provision into that application. If you don’t yet have a GitLab project to test, you can use this following one, just clone it on GitLab: > **[Gergely Imreh / get-me-an-advice](https://gitlab.com/imrehg/get-me-an-advice)** > > A simple project to get a piece of advice, and spice it up with colours! It has set up a small piece of code (a shell scipt that gets you a piece of advice, in nice colours!), and some testing instructions in `.gitlab-ci.yml`. Once you cloned it, go to your projects **Settings \> CI/CD** page, and select **Runners**. To make sure that you are using this new runner, click **Disable Shared Runners** on that page. Take note of the runner registration token: ![runners_page](https://global.discourse-cdn.com/balena/original/2X/2/22097e49f111350790874977fab3a62fece97739.png) Find the device you provisioned, and add a new service variable for the `runner` service called `GITLAB_TOKEN` with the value of your token. If things go well, your device will automatically register and will show up in a short time, after you refresh the page, something like this: ![Screenshot_2019-01-25_19-59-59](https://global.discourse-cdn.com/balena/original/2X/1/17db5ded74b8036a092a800ebe6b3df7a75bc5ac.png) Afterwards, you can go to to the project’s **CI/CD \> Pipelines** page, where you would see something like this. ![Screenshot_2019-01-25_20-02-07](https://global.discourse-cdn.com/balena/original/2X/7/711ac2d5288c7384169f3d1300de744499e80478.png) (It might happen, that the shared runners already run the job first when you cloned the project before they were disabled, you can clock on a result, and on the next page you can re-run it with the new runner you have). In the balena dashboard, you might see something like this in the device’s logs, which shows it’s running something: ![Screenshot_2019-01-25_20-35-12](https://global.discourse-cdn.com/balena/original/2X/8/8e096544c75ca1b4b200a0d96137a2824aaa0c25.png) And this is how the test logs are shown in GitLab: ![onetest](https://global.discourse-cdn.com/balena/original/2X/b/b846331627fd50e2702a34d8a436b7248f5cc6bd.png) Congratulations, you should be ready to run build jobs on your own devices! One of my jobs, run on a Raspberry Pi 3 can be found here: > **[test:generic (#151357287) · Jobs · Gergely Imreh / get-me-an-advice](https://gitlab.com/imrehg/get-me-an-advice/-/jobs/151357287)** > > A simple project to get a piece of advice, and spice it up with colours! The way it is set up, the same runner repository linked above works across architectures, I’ve tried on Raspberry Pi 1 (armv6), Pi 3, BeagleBone (armv7), ARTIK710 (aarch64), NUC (x86\_64), Edison (i686). To showcase the multiarchitecture nature of things, I’ve set up a variant of the above demo project, with this little testing rig: ![00-min](https://global.discourse-cdn.com/balena/original/2X/3/32f890166405c30a78c4d34a6a01e103fdd691ee.jpeg) These are 5 physical devices + a Virtual NUC on my laptop, a 5 different architecture, and they are building the test cases according to their device type tags. ![testrun](https://global.discourse-cdn.com/balena/original/2X/c/c44bd1bfdfce1fc07168786bfe8eed6c14f19083.png) You can see the results in this test run: > **[Pipeline · Gergely Imreh / simple-hello-test](https://gitlab.com/imrehg/simple-hello-test/pipelines/44843329)** > > GitLab.com (feel free to click around, and check the test results, that they were run on the actual device types, shown by the output of `/proc/cpuinfo` saved with the tests) ## Extra Notes The code sets up the runners by default to use the `balenalib/%%BALENA_MACHINE_NAME-debian:latest` image (ie. if your `.gitlab-ci.yml` does not speciy an image, that’s going to be run). You can see more notes, and the environment/service variables that can modify the behaviour of the automatically registered runner in the readme: [https://github.com/balena-io-playground/balena-gitlab-runner/blob/master/README.md](https://github.com/balena-io-playground/balena-gitlab-runner/blob/master/README.md) If you want to know more about GitLab runners, check out [their documentation](https://docs.gitlab.com/ee/ci/runners/README.html) and possibly their [advanced configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html) notes, which might come handy, if you want to register extra runners. That you can do by connecting to the `runner` service in the web terminal or over `balena ssh`, and check out `gitlab-runner --help`. For further details on the GitLab CI/CD infrastructure, check out [their docs](https://docs.gitlab.com/ee/ci/README.html). If you want to check out the runners’ source code, here’s the repository for that too: [https://gitlab.com/gitlab-org/gitlab-runner](https://gitlab.com/gitlab-org/gitlab-runner) ## What’s next? There are definitely a lot of things to improve on (configuration, ease of use, etc…). If you find any problem or have an idea for improvement, please [open an issue](https://github.com/balena-io-playground/balena-gitlab-runner/issues)! Or if feeling adventurous, send a Pull Request with your changes! 🙂 Or just ask here of you have any questions, share with us if you have some success story testing code with this project! Cheers! ---
**Author:** ![gusgonnet](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/gusgonnet/32/1461_2.png) [@gusgonnet](https://forums.balena.io/u/gusgonnet)\ **Post date:** [January 31, 2019, 3:35am UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090/2 "2019-01-31T03:35:44Z")
very nice project! Congrats ---
**Author:** ![imrehg](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/imrehg/32/36_2.png) [@imrehg](https://forums.balena.io/u/imrehg)\ **Post date:** [February 8, 2019, 5:02pm UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090/3 "2019-02-08T17:02:15Z")
Thanks, @gusgonnet, if you happen to use this project for something, would love to hear about it! 🙂 ---
**Author:** ![jalim](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/jalim/32/1021_2.png) [@jalim](https://forums.balena.io/u/jalim)\ **Post date:** [April 5, 2019, 2:39pm UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090/4 "2019-04-05T14:39:16Z")
@imrehg This is super cool! I am curious if you had any ideas adapting this to test automatically a balena application on the device? Would this envolve more of a balena-on-balena approach? ---
**Author:** ![imrehg](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/imrehg/32/36_2.png) [@imrehg](https://forums.balena.io/u/imrehg)\ **Post date:** [April 5, 2019, 5:55pm UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090/7 "2019-04-05T17:55:32Z")
@jalim that’s an interesting thing, my first inclination is that it is not obvious how, but definitely worth a try! We were thinking of doing test with such projects as > **[balena-io/wifi-connect](https://github.com/balena-io/wifi-connect)** > > Easy WiFi setup for Linux devices from your mobile phone or laptop - balena-io/wifi-connect in more of a stand-alone mode, but I think it _might_ work in general. Probably not for all the application types (for example not really for those, that require `config.txt` changes for the Raspberry Pi), and it might require replicating some functionality that is done by the supervisor now in the test script, but might just work… On the other hand, we are working on a pretty comprehensive on-hardware testing rig + framework, which might be able to bridge the gap. That’s for another day, I guess, this is cool inspiration for what we have now, so thanks! If we make anything useful like that, we’ll shout! ---
**Author:** ![imrehg](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/imrehg/32/36_2.png) [@imrehg](https://forums.balena.io/u/imrehg)\ **Post date:** [May 22, 2019, 10:34am UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090/8 "2019-05-22T10:34:30Z")
Did a few changes recently, just an update: ### 32-bit x86 runners Since the GitLab devs [declined to have x86 32-bit helper images](https://gitlab.com/imrehg/gitlab-runner/tree/v11.11.0-i386), and without helper images the runners don’t work, I’ve done my own little patching on the fork of the runner code, for example here: > **[Files · v11.11.0-i386 · Gergely Imreh / gitlab-runner](https://gitlab.com/imrehg/gitlab-runner/tree/v11.11.0-i386)** > > GitLab Runner and built the relevant images with `make helper-docker`, retagged things, and pushed them to Docker Hub at [https://hub.docker.com/r/imrehg/gitlab-runner-helper](https://hub.docker.com/r/imrehg/gitlab-runner-helper). The default setup of using these patched images for test devices like Intel Edison, fixed in this commit: [Automatic x86 32-bit runner images](https://github.com/balena-io-playground/balena-gitlab-runner/commit/193167956b490247ae0edd34b7853ac62d330f8f). ### Raspberry Pi 1/Zero balena-engine It turned out that the binaries we uploaded to the [balena-engine releases page](https://github.com/balena-os/balena-engine/releases) for the [17.12.0 release](https://github.com/balena-os/balena-engine/releases/tag/v17.12.0) in use do not totally work on armv5/armv6, or at least don’t work the way they should. While debugging that, for those device types I’m [installing regular docker](https://github.com/balena-io-playground/balena-gitlab-runner/commit/397ce9cb63c6ee7ccabe7f776d95a454e70e63be) for the moment - making the image larger, but also make `docker-gc` finally work, and the device won’t run out of space anymore, which is good 😛 Hopefully we can revert this to balena-engine soon. * * * With this, we have a pretty decent setup, that runs hundreds of tests for our base images, see more details at [Automated balenalib base image smoke testing with GitLab runners](https://forums.balena.io/t/automated-balenalib-base-image-smoke-testing-with-gitlab-runners/10045) ---
**Author:** ![benat](https://avatars.discourse-cdn.com/v4/letter/b/ac91a4/32.png) [@benat](https://forums.balena.io/u/benat)\ **Post date:** [November 28, 2019, 11:41am UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090/10 "2019-11-28T11:41:07Z")
Good jobs ! I am establishing CI/CD on my project and I am a remark concerning runner. On my pipeline, runner pulling image used to execute stages and some time later Supervisor remove these images on local registry. With this behavior, runner pulls again the same image. It’s possible to disable this default Supervision behavior ? Thanks, Ben ---
**Author:** ![Jetsonhawk](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/jetsonhawk/32/6416_2.png) [@Jetsonhawk](https://forums.balena.io/u/Jetsonhawk)\ **Post date:** [July 27, 2021, 1:00pm UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090/12 "2021-07-27T13:00:41Z")
Indeed, the selection process is the hardest especially when it comes to dicing into the ci/cd stuff. After exploring the [best ci cd tools](https://www.cloudways.com/blog/continuous-deployment-tools/), I got familiar with one of them mentioned tools in the blog and so to grip my focus for further development. Thanks for opening this awesome discussion. keep it alive! ---
**Author:** ![Jetsonhawk](https://sea2.discourse-cdn.com/balena/user_avatar/forums.balena.io/jetsonhawk/32/6416_2.png) [@Jetsonhawk](https://forums.balena.io/u/Jetsonhawk)\ **Post date:** [November 24, 2023, 3:05pm UTC](https://forums.balena.io/t/gitlab-runner-on-balena-devices-for-continuous-integration-testing/5090/14 "2023-11-24T15:05:55Z")
> [@Jetsonhawk](#): > > Indeed, the selection process is the hardest especially when it comes to dicing into the ci/cd stuff. After exploring the [best ci cd tools](https://www.cloudways.com/blog/continuous-deployment-tools/), I got familiar with one of them mentioned tools in the blog and so to grip my focus for further development. Thanks for opening this awesome discussion. keep it alive! It’s great to hear that you’ve found valuable insights in your exploration of CI/CD tools. Indeed, choosing the right tools is crucial for development efficiency and success. As you continue to refine your focus and delve deeper into development, having a reliable hosting provider can further enhance your workflow. In this regard, Cloudways is an excellent choice. It’s a platform that supports a wide range of development tools and offers a managed hosting environment that can seamlessly integrate with your CI/CD setup. Plus, Cloudways is currently offering a significant promotion: 40% OFF for 4 months on all hosting plans, along with up to 40 free migrations, using the promo code BFCM4040. This offer is valid from 13th November 2023 till 1st December 2023, and migration requests should be made within 4 months. This could be an opportune time to leverage a hosting environment that complements your development tools and goals.