Gitlab Workspaces - Beta feedback/suggestions/questions
Hello,
We were recently PoC-ing Workspaces on Gitlab self-managed instance (16.6.x, Premium) as a possibility for company-wide usage of this feature.
The solution itself looks quite promising for our use-case (supply devs with immutable, platform-controlled tooling for development), but there are several issues or features missing for us to go forward currently:
- Gitlab K8s agent can only be shared to projects under same root group
This is kind of a big one for us, since each cloud account gets it's root group with subgroups containing various repos pertinent to that account. We have 300+ such root groups, and enabling Workspaces for all of them means we have to deploy agent in each group, leading to huge waste of compute - that currently looks like a dealbreaker.
A much appreciated implementation would enable something akin to shared CICD runners, but for K8s Agents.
- There is currently a serious bug locking up KAS backend
More details here:
Looks like .devfile.yaml
isn't sanitized/linted properly before submission to reconciliation engine. In this case, we tried attaching two containers to workspace pod because it looked feasible using devfile schema docs.
- devfile locking
We would also like a good implementation of protecting devfiles from tampering by the devs, possibly to prevent issue nr. 2 above but also as a security measure. Having a possibility to use out-of-tree devfile (similar to using .gitlab-ci.yaml
from another repo) or better yet as a catalog for devs to chose from would be ideal.
- Cannot pull images from private container repositories
Currently we find no way to inject imagePullSecrets
into created Deployment nor inject Secret
with repo creds into a dynamically created NS. We bypassed this by using Kyverno policies, but that is far from ideal. Not deal-breaking, but still essential.
- SSHD config
Using non-root account to spin sshd
daemon and removing password on gitlab-workspaces
user is not ideal and is currently clunky, not to mention it has to be baked into the image itself. It would be better to implement some kind of sidecar to handle this.
- VSCode extensions
Currently there's no way to install extensions. We would be fine with a solution that requires baking that in into container images at the very least. Having the ability to use i.e. Python debugger in Workspace would greatly enhance its usability.
- Being able to mount multiple containers in a Pod
The way we found out a bug (nr 2) was trying to attach a ephemeral PSQL container to a Workspace pod via .devfile.yaml
. While this isn't supported right now, it would greatly enhance code development (similar to how you can attach service
container in CICD).
- Workspaces proxy helm chart not Gitops ready
I know it's early days - but Proxy Helm chart is not Gitops ready - tokens etc need to be passed as value, not as reference to Secret
holding the actual value.
My question would be - are these features/fixes on the roadmap? We have successfully PoC'd the solution but are reluctant to move forward without knowing if these are going to be implemented - and the timeline on when to expect them?
Finally - thanks on working on this feature! Personally I think it has great potential - but its still a bit rough around the edges.