I’m glad this was helpful.
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