The new CI/CD from Gitlab looks great... I am on Github otherwise I would definitely use it. In fact I find myself amazed by their development pace, every release is packed with stuff.
GoCD is a super simple CD platform (from user/developer point of view), easy to learn and with little possibility to snowflake it, with a Fan in dependency resolution that works nice.
The UI is not awesome but does the tricky for support teams and others.
BTW I have no association to any of the CD/CI companies I just like to work on this topic.
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).
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/
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).
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.
Support has had trouble scaling, we just hired a director to make sure we get on track, sorry about that.
Having you builds fail intermittently is bad, this should be a problem only on GitLab.com Reliability of that is not where it should be and we're taking drastic actions to improve it. If anyone reading this is up for the challenge please see https://jobs.lever.co/gitlab/a9ec2996-b7b6-4d87-aed0-1fc2ce3...
It is actually 45 days and in our subscription terms, Section 5.2: "If Customer terminates this Agreement pursuant to Section 6.2 within 45 calendar days from receipt of the initial invoice for the Licensed Materials, GitLab will refund all Fees paid hereunder."
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).
