I’m looking to get in contact with the guys developing the gitlab-runners charm: gitlab runner | Juju
Its great work and would like to know more about how to use it pulling custom lxd images for use in a CI/CD pipeline. I’m not sure how its done and I’d love to know.
The background is that we have a custom compiler, which I would like to place in an lxd remote image to be installed by the gitlab-runner using the “image” directive to the custom runner. I’m not sure how this can be achieved.
The guys behind the gitlab-runner charm might know… or someone else =D Rick Harding was mentioning this “lxd runner approach to compiling” during a session we had some time ago and its now getting closer to reality and exploring how to compile custom codes with custom compiler on LXD seems like a good way here.
As far as the gitlab-runner goes, I believe that the image tag is used to define a docker image to run, rather than a general purpose image (LXD, for example)
Thanks for the kind words around the work on the GitLab runner charms. I definitely can’t take all the credit, @chris.sanders did the bulk of the LXD work on top of the charm, so may also have input here too.
If you’ve got specific goals in mind you need help with, happy to help. An example you might find useful is a project I’ve been working on to build Ubuntu Core gadget snaps (for enabling devices to run Ubuntu Core) and building those atop Juju-deployed GitLab using LXD runners. The snap is built (which includes cross-compiling the bootloader and kernel with custom toolchains) inside the LXD environment and controlled with the .gitlab-ci.yml file.
Take a look at this example and let me know if you have any questions!
That is absolutely perfect for some of my own use-cases and I will try ping in some other people working closer to embedded development for this.
My first question is if this charm would support pulling in remote lxd images and custom lxd profiles or if you would be interested in adding that support down the road? (That would enable us to create build systems with custom compilers we use…)
Secondly, I have a more challenging use-case that I would love your advice and opinion on. It is that of “how to build code dependent on and targetting Microsoft windows”. So far, we are thinking along the line of a qemu executor with a virtual windows microserver, but we are still trying to understand exactly how our problem looks like.
The underlying driver for this work, is to try streamline our CI/CD pipelines. But we might push this to far.
For custom image support - I saw this in your initial query, and offered up the above example to show how I was adding a custom compiler as part of building a snap - but if you’re not building snaps, you could either add the steps to include the compiler to the .gitlab-ci.yml - but I understand why you’d want to use a custom image, as toolchains are often big and expensive to install in each CI run.
We currently hard-code the image used when running LXD images, and this is due to a bug/limitation in GitLab - we use a “custom” executor to implement LXD, and the creation and configuration of the container is handled by scripts that prepare the LXD prior to running the job. GitLab previously did not supply the value of the “image” configuration value for “custom” executor jobs, so we currently have no way to get the desired image from the .gitlab-ci.yml file on run. This looks like it has been added to the runner, and would could check the value of the $CUSTOM_ENV_CI_JOB_IMAGE environment variable, and use that to configure the image used to create the LXC container. That would be a fairly simple change, if that would work for your use case?
For the custom LXD profile, I think the same approach would work. We could have a charm configuration item that would take profile customisations and then the preparation script that creates the LXD container for the CI job could be customised with that profile/those config settings, but that too would be pre-runner rather than per-job.
For Windows support, the GitLab option seems to be supporting the VirtualBox runner. I think in this case, we could in theory extend the charm to install VirtualBox and provide a virtualbox runner, which would allow creation of Windows VMs and therefore running CI jobs on windows. That will be a fair bit of work, but it’s definitely possible, and I would say that PRs are always welcome on that one
Our own private gitlab-runner adds a few features for managing a local proxy setting. This prevents us currently from using your version and contribute to the work.
Would it be possible to work with you to implement/merge the support for proxy-settings and subsequently try these things above? I can suggest it internally if you think we can collaborate on it?
Absolutely - if you drop an issue and/or PR here we’ll gladly help to get support for proxy servers merged, that would be a cool feature to support, as I suspect a lot of folks who are looking to self-host their CI/CD will also be wanting to use proxies for external access. I believe we have worked around this in the past by using the Juju model’s HTTP proxy settings, but this does not cover all use cases.
