Mikhail Mazurskiy: Is the issue setting Context?Hordur Yngvason: There are just two things to fix: Setting context and CI variables that are set by GitLab Cluster integration, Kubenamespace, Kubetoken etcMikhail Mazurskiy: Docs needed for ADO => Agent?Hordur Yngvason: Working out of the box would be betterNicholas Klick: can we just ask them to add a ci.yml?Mikhail Mazurskiy: Starting with Config as code is a better pattern.Hordur Yngvason: Users might be concerned about adding a ci.ymlMatt Kasa: Seems like we need to support users that dont want a ci.ymlMikhail Mazurskiy: ENVs?Hordur Yngvason: CI vars could work.
One of the drawcards of Auto DevOps is review apps. But I think this depends on the existing cert-based method to dynamically provision namespaces and service accounts, and the agent does not support this either (#273656 (closed))
I'd like to ask us to discuss the current Auto DevOps offering with a perspective of how can we support it with the Agent. Beside looking at all the features of Auto DevOps at a high level, I'd like to dig deep into review apps.
A few notes to get started:
Let's assume that the CI tunnel is ready.
I'd propose to NOT add direct helm support to the agent. We can run helm template, but based on the interviews run recently, adding helm does not seem to be a preferred approach to experienced teams. On the other hand, I'd recommend to think about kustomize support. (I don't know if that can be of interest for deployments and review apps.)
Be cognizant about possible restrictions mostly related to OpenShift. It would be cool to have it supported too.
As part of (or a prelude to) this discussion, I'd love to see what ADO would be hired to do, in terms of JTBDs that support the ADO vision.
This may also be what @mvrachni is asking for in #299350 (comment 497083342). While it's great to have a discussion on how to support ADO with the agent, documenting all the JTBD for ADO is a useful exercise and should be started early in this ADO restart process.
@Viktor Nagy @tkuah If we don’t know the exact direction we want to take for Auto DevOps, do you think it’s valid to support the current solution with the Agent? Or is the purpose going to be to find a solution for Kubernetes that will fit in any sort of vision we come up with?
There are features in the current Auto DevOps that users aks for, they don't really ask for Auto DevOps, but that's what we have a name for. What we really see there are security scanners and review apps. We want to support these, not Auto DevOps, but I don't have a better way to speak about it. I'm sorry for the confusion.
+100, it's really security scanners and review apps. But I want to add that we have the ambition of users heavily using GitLab to deploy to production apps too.
+100,, I agree that the scanners and deploy jobs are heavily requested where not only is review apps important, but also deploying to staging, production, as defined in the Auto_deploy part of AutoDevOps.
The user flow of Creating a gitlab account, creating a project/group and going to the CI/Kubernetes menu and having your linked google account allow you to automatically create and setup a cluster is awesome. Ideally this should then auto setup the ingress, certmanager and agent.
Then the user points their domain to the ingress ip, ideally gitlab should show what IP to point to.
From here the user should just be able to create new project in the group, have autodevops run and have a subdomain app working. Extra points would be to have a graphical form that can help configure the .gitlab-ci.yml with the auto template, especially the POSTGRES_ENABLED and ADDITIONAL_HOSTS variables these took me forever to figure out.
I hope this doesn't sound too demanding, but I really believe that if gitlab can get the flow newbie friendly, while being customizable, it will be huge enabler for many beginners.
@rvdende It's our long term plan to improve the usability for beginners too. We believe that providing the core features focused around experienced users will allow us to build more convention into the product later, and together with these conventions we can add more automation and opinions too. It will take us some time to get to the status that you described, but we are on it. Thanks for your feedback!