3 ms·

What can we improve in GitLab that would make you stay?

by sytse 9y ago

kerny 9y ago
No OP, but IMHO GitLab is getting quite heavyweight and that's why people are looking for more lightweight alternatives.
InternetOfStuff 9y ago
Sytse, thanks a lot for being present in the community. It's most appreciated, and I always look forward to your comments. With regards to your question: I agree with user kerny. Stop packing stuff on top. What I want from Gitlab is to use it to manage my repos. If you improve that aspect (which is already fine though IMO), you'll make me happier. If you improve Gitlab integration with other CI tools, you'll make me happier. If you improve your CI solution (which I found lacking when I evaluated it 1.5 years ago -- no idea how it's now), I still won't use it -- I explicitly don't want to rely on one, integrated solution. In my experience, such integrated solutions are fine for a while, until they aren't. My use cases tend to expand to things the integrated solution doesn't provide, and them I'm stuck. Do one thing, and do it well. Doing yet more things detracts from Gitlab's appeal. Personally, I wouldn't mind you utterly removing Gitlab's CI tool (I know, not gonna happen, and that's fine -- just saying).
- pas 9y ago
  GitLab does one thing. And GitLab CI/CD does one other thing. GitLab Image Registry does yet an other thing pretty well. And GitLab Omnibus also does one thing. (It bundles those.) Making it more configurable (as in makeing more features disable-able) would be nice though.
  - sytse 9y ago
    Thanks InternetOfStuff for using GitLab and both you and pas for your kind words. We think there is a lot of value in a single application for the complete DevOps lifecycle https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/ and we'll continue to build that in 2018. We'll also keep improving the existing parts of GitLab, such as the managing of repo's https://about.gitlab.com/direction/#code-review https://about.gitlab.com/direction/#code-review We want to play nice with other CI tools and for example have great support for Jenkins https://about.gitlab.com/features/jenkins/ https://about.gitlab.com/features/jenkins/ If you didn't use our CI since 1.5 years give it a shot, it is very good https://about.gitlab.com/is-it-any-good/#gitlab-ci-is-a-leader-in-the-the-forrester-wave https://about.gitlab.com/is-it-any-good/#gitlab-ci-is-a-lead... We don't want you to get suck with an integrated solution that is bad. We'll make sure that we'll keep improving every aspect of GitLab together with the wider community (100+ contributions in the last month). And if you want to use GitLab with something else you're welcome to https://about.gitlab.com/features/github/ https://about.gitlab.com/features/github/ And as a GitLab user you can turn off the things you don't want under project settings https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions https://docs.gitlab.com/ee/user/project/settings/#sharing-an... Please let us know if there is anything we should add there.
theptip 9y ago
Thanks for taking the time to ask. My primary concern is that instead of polishing the features that have already been released, the platform is trying to do too many new things. Some of that stuff is cool (k8s monitoring integration, though EEP is too expensive for me, and my Grafana dashboard does basically the same thing), while some of it seems a bit bloated (SAST/DAST for example, which was a few lines of code to implement ourself). I really want the core Github replacement use-case to be as ergonomic as Github is. And the CI/CD piece is also great, but still has plenty of rough edges (e.g. Environments are a great feature, but I still can't clean up stale ones, which makes the environment list basically useless). My experience with support has been a bit lackluster; e.g. see https://news.ycombinator.com/item?id=16897644 https://news.ycombinator.com/item?id=16897644. General reliability in CI/CD is not great; I'd say something like 0.25-0.5% of my build jobs fail from intermittent infrastructure failures (mostly gitlab runner/API issues from what I can tell), which wasn't a problem when I was using Jenkins. Ops is still a significant concern; site reliability has improved in the last year, but that's not saying a lot; it's still a fairly frequent occurrence to get errors during/after a deploy. I'm not sure if this problem would be better or worse if I self-hosted, as I don't know how hard it is to run a GL instance (seems like it's hard, given how often the gitlab.com site has issues). Performance has also improved in the last year, but the site is still on the slow side (e.g. compared to contenders like gitea). Oh, and the pricing model is a bit broken -- all of the other SaaS platforms that I use let me pay monthly (at a higher rate); when I was evaluating paying for gitlab.com vs. doing self-hosted EE, I really wanted to pay for my team to use the hosted offering for a few months to see how things went, but I wasn't prepared to lock in for a year, so I didn't end up trying out the hosted paid offering. None of these points in isolation is enough to make me leave the platform and go back to Jenkins, but they are enough to make me pay close attention to the alternatives.
- pas 9y ago
  > SAST/DAST for example, which was a few lines of code to implement ourself Could you elaborate on that please?
  - theptip 9y ago
    Sure, if you dig into the SAST Dockerfile you'll see that it's running `bandit` if you're in a Python repo. So add this step to your .gitlab-ci.yaml: bandit-check: # This check runs Openstack Bandit, a Python static analysis tool that checks for security issues. stage: unit-test script: - bandit -r -x 'tests,test_,/migrations/,./src/' -c bandit-config.yaml -ll ." DAST uses ZAP, which you can also run in a Dockerfile yourself. Of course there's also some window dressing to display the errors on the main MR, instead of having to dig into a step failure, but that doesn't make a meaningful difference to me. (This feature could well have moved on since it was first implemented, that was the only time I dug into it).

What can we improve in GitLab that would make you stay?

by sytse 9y ago

What can we improve in GitLab that would make you stay?

No OP, but IMHO GitLab is getting quite heavyweight and that's why people are looking for more lightweight alternatives.

InternetOfStuff 9y ago

Sytse, thanks a lot for being present in the community. It's most appreciated, and I always look forward to your comments. With regards to your question: I agree with user kerny. Stop packing stuff on top. What I want from Gitlab is to use it to manage my repos. If you improve that aspect (which is already fine though IMO), you'll make me happier. If you improve Gitlab integration with other CI tools, you'll make me happier. If you improve your CI solution (which I found lacking when I evaluated it 1.5 years ago -- no idea how it's now), I still won't use it -- I explicitly don't want to rely on one, integrated solution. In my experience, such integrated solutions are fine for a while, until they aren't. My use cases tend to expand to things the integrated solution doesn't provide, and them I'm stuck. Do one thing, and do it well. Doing yet more things detracts from Gitlab's appeal. Personally, I wouldn't mind you utterly removing Gitlab's CI tool (I know, not gonna happen, and that's fine -- just saying).

pas 9y ago
GitLab does one thing. And GitLab CI/CD does one other thing. GitLab Image Registry does yet an other thing pretty well. And GitLab Omnibus also does one thing. (It bundles those.) Making it more configurable (as in makeing more features disable-able) would be nice though.
- sytse 9y ago
  Thanks InternetOfStuff for using GitLab and both you and pas for your kind words. We think there is a lot of value in a single application for the complete DevOps lifecycle https://about.gitlab.com/2017/10/11/from-dev-to-devops/ https://about.gitlab.com/2017/10/11/from-dev-to-devops/ and we'll continue to build that in 2018. We'll also keep improving the existing parts of GitLab, such as the managing of repo's https://about.gitlab.com/direction/#code-review https://about.gitlab.com/direction/#code-review We want to play nice with other CI tools and for example have great support for Jenkins https://about.gitlab.com/features/jenkins/ https://about.gitlab.com/features/jenkins/ If you didn't use our CI since 1.5 years give it a shot, it is very good https://about.gitlab.com/is-it-any-good/#gitlab-ci-is-a-leader-in-the-the-forrester-wave https://about.gitlab.com/is-it-any-good/#gitlab-ci-is-a-lead... We don't want you to get suck with an integrated solution that is bad. We'll make sure that we'll keep improving every aspect of GitLab together with the wider community (100+ contributions in the last month). And if you want to use GitLab with something else you're welcome to https://about.gitlab.com/features/github/ https://about.gitlab.com/features/github/ And as a GitLab user you can turn off the things you don't want under project settings https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions https://docs.gitlab.com/ee/user/project/settings/#sharing-an... Please let us know if there is anything we should add there.

theptip 9y ago

Thanks for taking the time to ask. My primary concern is that instead of polishing the features that have already been released, the platform is trying to do too many new things. Some of that stuff is cool (k8s monitoring integration, though EEP is too expensive for me, and my Grafana dashboard does basically the same thing), while some of it seems a bit bloated (SAST/DAST for example, which was a few lines of code to implement ourself). I really want the core Github replacement use-case to be as ergonomic as Github is. And the CI/CD piece is also great, but still has plenty of rough edges (e.g. Environments are a great feature, but I still can't clean up stale ones, which makes the environment list basically useless). My experience with support has been a bit lackluster; e.g. see https://news.ycombinator.com/item?id=16897644 https://news.ycombinator.com/item?id=16897644. General reliability in CI/CD is not great; I'd say something like 0.25-0.5% of my build jobs fail from intermittent infrastructure failures (mostly gitlab runner/API issues from what I can tell), which wasn't a problem when I was using Jenkins. Ops is still a significant concern; site reliability has improved in the last year, but that's not saying a lot; it's still a fairly frequent occurrence to get errors during/after a deploy. I'm not sure if this problem would be better or worse if I self-hosted, as I don't know how hard it is to run a GL instance (seems like it's hard, given how often the gitlab.com site has issues). Performance has also improved in the last year, but the site is still on the slow side (e.g. compared to contenders like gitea). Oh, and the pricing model is a bit broken -- all of the other SaaS platforms that I use let me pay monthly (at a higher rate); when I was evaluating paying for gitlab.com vs. doing self-hosted EE, I really wanted to pay for my team to use the hosted offering for a few months to see how things went, but I wasn't prepared to lock in for a year, so I didn't end up trying out the hosted paid offering. None of these points in isolation is enough to make me leave the platform and go back to Jenkins, but they are enough to make me pay close attention to the alternatives.

pas 9y ago
> SAST/DAST for example, which was a few lines of code to implement ourself Could you elaborate on that please?
- theptip 9y ago
  Sure, if you dig into the SAST Dockerfile you'll see that it's running `bandit` if you're in a Python repo. So add this step to your .gitlab-ci.yaml: bandit-check: # This check runs Openstack Bandit, a Python static analysis tool that checks for security issues. stage: unit-test script: - bandit -r -x 'tests,test_,/migrations/,./src/' -c bandit-config.yaml -ll ." DAST uses ZAP, which you can also run in a Dockerfile yourself. Of course there's also some window dressing to display the errors on the main MR, instead of having to dig into a step failure, but that doesn't make a meaningful difference to me. (This feature could well have moved on since it was first implemented, that was the only time I dug into it).