dgruesso
Joined 12 years ago
Karma
5
Submissions
8
Member since
May 5
Recent submissions
Comment · 7 years ago
Comment · 7 years ago
GitLab PM here. Auto DevOps makes use of herokuish in order to find the language of your project. Herokuish images are Ubuntu-based, and it doesn't allow the use of specialized images. One can always provide a dockerfile (based on the image of your choice) and Auto DevOps will use that instead.
Comment · 7 years ago
Hi jbergstroem. GitLab PM here. thanks for the feedback. Our vision is indeed ambitious and we recognize that not all of our categories are yet "complete" (more on our category maturity here https://about.gitlab.com/handbook/product/categories/maturit...). While we are aiming to make GitLab a first class application for operators, we continue to focus on the developer lifecycle at the same time. You can see what each of our groups is focusing on upcoming releases here https://about.gitlab.com/direction/configure/#upcoming-relea.... I'd love to learn what areas and level of insight you'd like to see in out application that would make you consider using it as your daily ops-land driver. Thanks.
Comment · 7 years ago
Hi @sigi45, GitLam PM here. Thanks, I'm glad you like GitLab and have noticed the improvements we've been working on for Auto DevOps. I'm sorry things didn't work out of the box for you, we've worked to cover many use cases but we recognize we don't yet cover them all. If the particular stage in question is not supported you have a couple of options: 1) you can disable the particular job in question with the use of environment variables (see https://docs.gitlab.com/ee/topics/autodevops/#environment-va...) or you can use composable Auto DevOps to only pull in the parts that are relevant to your project and use a customized CI script that fits your application better. More info on composable Auto DevOps here https://docs.gitlab.com/ee/topics/autodevops/#using-componen.... Is your project public by chance? Would like to take a look and make sure we do what we can to support it. Thanks.
Comment · 7 years ago
Hi bvm, GitLab PM here. Sorry to hear your dev cluster broke. Would like to offer any help we can provide and if possible learn more about the failure so we can take corrective action to avoid this in the future. Thanks.
Comment · 8 years ago
Hi, GitLab PM here, thanks for the mention. We're indeed trying to make use of kubernetes inside GitLab as simple as possible. And just to add to your comment, you can try out kubernetes integration (https://docs.gitlab.com/ee/user/project/clusters/) independent of auto devops and vice-versa (https://docs.gitlab.com/ee/topics/autodevops/). Both of these are available in our core offering.
Comment · 8 years ago
Thanks for the feedback Don.
For your particular use case, you could use the same cluster for multiple environments if you have separate namespaces and use separate service accounts for each. Using RBAC will further ensure you don't have any collisions, this way if there's an error in development, the production namespace will remain untouched.
When deciding which features are paid vs free we ask ourselves if the particular feature may be more relevant to larger organizations; that doesn't necessarily mean there won't be a use case at smaller companies, but just wanted to let you know our reasoning. You can read more about it here: https://about.gitlab.com/stewardship#what-features-are-paid-....
Comment · 8 years ago
Hi ratiolat, another GitLab PM here. Thanks for the feedback, as jl-gitlab mentioned, we'll work to make that clearer. You can think of Auto DevOps as a CI template that has a job for all devops stages built-in. If you want to experiment with kubernetes first you can easily add a kubernetes cluster from GitLab and experiment using with CI with or without auto devops. More info here: https://docs.gitlab.com/ee/user/project/clusters/
We are working to make Auto DevOps smarter and only run in cases where it can add value (https://gitlab.com/gitlab-org/gitlab-ce/issues/57483).
I agree with you, we don't currently cover all the use cases we'd like to, but we're working to expand the feature set and technologies we cover.
If you had a particular use case that was not well covered, I'd love to learn more about it so we can evaluate related improvements. You can reach me at daniel at gitlab dot com. Thanks.