Can't help but feel that their focus on moving all operation insights into gitlab itself will not be as successful as they want it to be (as far as I read, their goal was to replace their operations and monitoring tools with gitlab itself[1]). I've worked with the ultimate edition for a year and the kubernetes integration is nowhere close to the insight you would get from google, amazon or azure in terms of insight and integration with ops-land. I wish all these hours were spent on improving the developer lifecycle instead.
I can understand how their huge success of "built-in CI" quickly leads to "built-in XYZ", but competing with github that lets other companies solve developer/ci problems via marketplace (and now CI via their new terraform actions) may lead to loosing market-leader [my take on their product] position for a code/test/review/merge ecosystem.
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.
GitLab has really come a long way in the past few years. The days of being a github-alike are long gone. Very happy to see them continue to find success.
Amen. Gitlab is to GitHub what AWS is to DigitalOcean. GitHub is great don't get me wrong, especially for open source general releases. But gitlab lets you actually build pipelines and fully integrate a bunch of services. They're the best CI/CD service around, honestly, and I think they've been playing to that strength. On top of that they have excellent project management, which makes them a lot more suitable than GitHub for company project's imo.
Github UI/UX for what if you don't mind me asking?
I use both regularly (gitlab instance for my company, gitlab hosted for my side project, github for my personal site and toy projects and other people's projects) and while I hate neither, there is nothing really to love about Github's UI.
I think they both do quite well, with minor trade-offs that are a function of which features they have front and center (CI runners for gitlab, issue tracking and community for github).
I still have some issues with the Gitlab UX but they've improved it a lot in the past couple of years. Especially knowing that there are way more features than a few years prior (and WAY more features than on Github), they manage really well IMO.
I dont like the way the breadcrumbs work (do people still use the term breadcrumb? I'm old) and I've got this one repo that is always on the 2nd page of the list. That's my gripes about gitlab. I reckon it's a great product.
If that repo is one of your frequently visited projects, you'll be able to quickly access it through the “Projects” dropdown in the header. Does that help?
Breadcrumbs refer to the link/hierarchy list thing near the tops of pages which goes something like "org name > project name > issues" and you can click on one of those to go back to that level. I think you might be thinking of a different feature.
In case somebody from Gitlab team is reading, a lot of people want to have runner priorities in gitlab - the feature seems to be trivial, yet can save a lot of time and money for the user for you can use less ondemand runners or give more work for more powerful runners
It's amazing how good Gitlab is for a free product.
Interestingly, the fact that we need to host some of our repos internally means we have an on-site install, but because of that I much prefer to host our public / non-internal repos on gitlab.com rather than github, because I can use a single workflow / UI / system for all our projects. So steadily all my open source etc. is moving to gitlab.com because of this effect.
Thanks to the team at Gitlab who make all of this available for everyone to use!
Saying Gitea is better because it's lighter weight is like saying a moped is better then an SUV because it's lighter weight. Gitea / Gogs is great for personal projects and small teams that don't need all the CI/devops/scrum/etc features that GitLab provides, but they're not really in the same ballpark.
GitLab is definitely resource hungry, but we self-host it for under $100/mo on AWS. This includes the cost of the CI infrastructure as well - EC2 instances being spawned by the multi-runner with docker+executor for each unique pipeline running.
Management of the server has been as easy as logging into the GitLab server periodically and running a yum update... It's never gone down.
Gitlab didn't have those extra features at early stages either (Gitea does have CI API BTW, if not a built-in CI). And Gitea doesn't have Gitlab's financial resources.
But the point being made is orthogonal to the feature set: Gitlab (mostly written in Ruby) isn't using hardware resources (memory, CPU cycles, parallelism) as efficiently as Gitea (written in Go) does.
This is well reflected to the minimal system requirements, even when you aren't using any of those additional features:
https://docs.gitlab.com/ee/install/requirements.html whereas you can in principle use Gitea even on a Raspberry Pi Zero for a small group.
For example, disregarding parallelism and wasted CPU cycles and just looking at memory usage: I have a running instance and its using 30MBs of RAM at the moment (~10 users, ~100 repos). If I move all the repos, issues, PRs to a Gitlab instance, I would be looking at GBs according to their minimal requirements. This is related to the mindset in which memory and CPU are considered as infinite resources.
Hi! Thanks for the feedback. We'd love to be as lightweight as Gitea, but our end goal of being a single application for the entire DevOps lifecycle means that we are naturally more complicated. We are always working toward improving our resource usage though! You can see our issues around performance here: https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
very true, running gitea myself for 2 years, easy to use, light-weight(one go binary to run, one minute painless upgrade with new releases), no memory/cpu pressure whatsoever(I host linux kernel tree myself, so yes large git is fine there too).
If you don't need what gitlab/github or for that matter Azure Devops, offers... using bare remote repos over SSH+FS might just be a better approach. All you need is an SSH server with file system access behind it.
Honestly, it's painless. Fire up a cloud server, run the omnibus installer and you're away. I can't remember having any serious issues in five years running it that way.
The decisions to include features based on price tier has seemed to grow increasingly petty IMO. We are on the Bronze tier, and won't upgrade because of a feature like this specifically. But each time I see that we don't get new features like this, I lose a little bit of that love I've had in GitLab as a user for over 4 years now.
While using the free tier, I honestly can't validate a a $19/user/mo ($228/user/annum) expense based solely on a single feature, let alone why I should move to the paid version at all if more and more features start to be gated beyond multiple levels (a la Windows 7).
I love using Gitlab as a part of development cycle, managing issues and handling pull/merge requests but per seat licensing is a bit steep for a single user, even more so for a team.
The norm for pricing products and services is more and more "just for a pint/coffee/sandwich a month" but when everyone wants their share of the cash, the end result is a mismash of services and products that don't work together well (if at all) and you get stuck without a pint/coffee/sandwich for the whole month now.
You don't think you get enough value out of Gitlab to justify the seat price?
Based on the fact it seems to power all (or majority) of your development process it seems like it would be worth it?
I'm sorry you feel that way. There is a lot of thought that goes into our pricing and what tier a feature should go in. At the end of the day though, we still need to make money as a company. If you're interested in how we determine which tier something goes in, you can read about it here: https://about.gitlab.com/handbook/ceo/pricing/#the-likely-ty...
A really simple way to improve the UI is to just add some margins on the right and left of the page. It's very off putting to have meaningful content butted up against the absolute edges. Not sure why this is, but I really hate interacting with gitlab because of it. Hope that helps.
We prefer 990px containers where possible, so if you're using gitlab on a browser smaller than that it'll usually butt up against the edges.
Couple of questions about your issue:
1. Any pages this is particularly bad for? Some dense pages (e.g. Pipelines or side-by-side diffs) need all the width they can get
2. what screen size do you normally use?
3. In Settings > Preferences > Behaviour, are you using Fixed layout or Fluid? Fixed should give you left/right margins if your window is >1280px
4. Do you collapse the left/right sidebars? I usually keep them both collapsed which helps reduce the crowding. But since they are expanded by default this is not an ideal solution
The main middle section is fine, your eye doesn't have to travel far to read the code files and the readme because it's in your primary viewing area.
But you know what's not in your primary viewing area? All of the buttons that do important things. They're shoved off to the side. If you want to do anything other than read the code files, you need to be looking at the exact leftmost edge of your screen and away from the main content. It's a disjointed viewing experience.
Ok, now the main content AND the most important buttons (navigation) are shoved to opposite sides of the screen. There is no max width on the main content, so your eye has to travel a veritable mile to read all of the content for each issue.
If I had to put my finger on the primary reason for this design, it's probably an over-focus on the idea that you should feature some "main content" for each page and kind of hide what you believe is "superfluous".
For example, "oh they clicked on an issue, so they really only care about the discussion that is taking place. Let's feature the discussion text but make all of the metadata shoved to the side and even collapsible." But the problem with this line of thinking is that the user _does_ care about more than just the "main content" of a page. The metadata, the navigation, it's all factored into a typical user experience. So when you are making the decision for the user about what they _should_ be looking at, you're forcing them to break your flow to do what they want. Now the user has to dart their eye from the far left to the far right just to see what they want.
I know I didn't answer your numbered questions directly, but I hope I'm conveying this correctly. I've never made a gitlab account, so I just use the default settings.
Our navigation was redesigned about 2 years ago (https://gitlab.com/gitlab-org/gitlab-ce/issues/32794), and we conducted a lot of research and user studies to ensure we were creating the best possible experience (https://gitlab.com/gitlab-org/gitlab-ce/issues/34917). All the navigation items to get to different pages within a project are contained in the left sidebar, while the buttons on the main portion of the screen are directly related to the current page.
We're currently also in the process of rethinking the right sidebar. It's getting cluttered, and there are items in there that probably aren't as frequently used as others. I've opened an MR to test a new design idea- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27752.
We're also conducting research to find out which items are most frequently used/most important- https://gitlab.com/gitlab-org/ux-research/issues/134 (the issue is private, but will be made public once the studies have been completed).
Hopefully this addressed at least some of your points. Please feel free to open some issues with any other ideas you have.
It took me an embarrassingly long amount of time to find where the code changes are in the UI. It seems like the actual content of the MR is the most important part and should be up at the top with the title and text description.
I think if I had to summarize my take on Gitlab UI, it would be claustrophobia (sidebars closing in on me) and information overload (what am I looking at or what _should_ I be looking at).
Thanks for taking the time in this interaction! :)
When GitLab starts to fully support automatic Let's Encrypt certificate generation with GitLab Pages — just like GitHub, I would strongly consider moving.
AFAIK it's in the pipeline to be added, but seems to not be a #1 priority[1]. Please let me know otherwise.
Out of literally bajillion features GitLab provides from DevOps lifecycle to project management and everything in between, Lets Encrypt certificates is what will make you switch? Are you serious?
Why would I not be? I see it as a feature that I would like to exist. And yes, they to have many features, but atm. I don't use them to the extend that I must switch at this second.
For future school project, I do see myself using GitLab. As you yourself said, they have many good features. (After been forced to used Bitbucket for a school project, I'm happy to use anything else.)
Hi! It is actively being worked on, but it didn't make it into this release. It is scheduled for the 11.11 release, and we don't foresee it being pushed back any further. Thanks for your feedback!
Why not? You might not be able to automatically hook it in via their UI, but can't you just do everything with the CLI in the GitLab CI? I mean I don't see a reason why this wouldn't work.
Overview of the three main improvements in this release:
1. Pipelines on the Operations Dashboard The Operations Dashboard allows users to have an overview of project information throughout the entire GitLab instance. You add individual projects, one by one, so it’s flexible to whichever specific projects are of interest. Also, the pipeline status information is added to the Operations Dashboard. This should help teams view the pipeline health of all the projects that they care about, together in a single interface. [1]
2. Pipelines for Merged Results When working in a feature (source) branch, it’s normal to have it diverge over time from the target branch if you aren’t rebasing frequently. This can result in a situation where both the source and target branch’s pipelines are green and there are no merge conflicts, but the combined output will result in a failed pipeline due to an incompatibility between the changes. By having your merge request pipeline automatically create a new ref that contains the combined merge result of the source and target branch, then running the pipeline against that ref, GitLab can better ensure that the combined result will be valid.Please note that if you are using merge request pipelines (in any capacity) and you use private GitLab runners that are version 11.8 or older, you will need to upgrade them to avoid running into the issue described in gitlab-ee#11122. Users of GitLab’s shared Runner fleet are not impacted. [2]
3. Suggest changes to multiple lines Collaborating on merge requests often involves spotting problems and suggesting a solution. In GitLab 11.6, we introduced support for suggesting a change to a single line. With 11.10, changes can now be suggested to multiple lines when leaving a comment on a merge request diff, and accepted with a single click, by any user with write permissions to the source branch. [3]
One thing that always seems a but more complicated at gitlab is to get a full overview/dashboard of my companies projects/repos. Has anyone found a better way to deal with that?
One option would be to add your most important stuff to the Operations Dashboard, since the button for it is always shown up top. You can also set it as your home page (Settings - Preferences - Default dashboard)
We already use it and it's getting better at every release. However there is few pain point that makes it hard to use for non-agile projects and planning. One is the ability to set the desired start date of an issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/39862
I like gitlab very much and i see that they improve there autodevops feature. That looks promising that i now can include single steps.
I'm playing around with autodevops and currently it sucks. I cloned there script and the helm chart otherwise it is not possible to just use it.
And quite frankly if you promote it as auto and enable it on default and it is not able to build a standard spring boot application or a angular frontend, i'm a little bit disappointed.
there is also a bug open for frontend builds: It is able to detect and build the anguluar project but is not able to execute karma tests because the image doesn't contain chromium. And for the backend there is another bug: autodevops builds the spring boot application and enables/enforces postgresql ssl but the image from gitlab for postgresql doesn't support it.
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.
I personally have asumed that when you introduce autodevops, you would make sure that the top x default stacks are working fine. Spring Boot and Angular are very popular (i believe) but they don't work out of the box but not much is missing.
My only gripe with gitlab is that gitlab-runner config is mutated by the runner itself. This makes it extremely hard to deploy gitlab-runners reliably and reproducibly in a declarative fashion which is kind of ironic given their whole sales pitch is "ci/cd".
I want to like GitLab, but the (comparative) lack of integrations is a showstopper.
For instance in our Github, Code Climate runs against all pull requests and adds comments on files when it detects quality issues (as a bot user).
I get this is up to companies like Code Climate to build, but having done a bit of integration building myself, the platform and marketplace strategy at Github is just so much more mature and thought out. The GitLab marketplace/integrations capability feels very much like an afterthought (no bot users for one thing).
Would love to see GitLab focus on making a broader platform & marketplace play, and working with big ecosystem players to really enhance the GitLab offering.
Interesting feedback. Could you give a few more examples? For instance, if you could build your DevOps toolchain and add any 3rd party integrations to GitLab, what would they be?
DevOps toolchain you've got covered. Your pipelines are pretty neat.
One thing I really like about GitLab is seeing pipeline errors in the merge request. For instance, we have rspec bubble up failures and they're right there in the test summary on the merge request. GitLab shows us a check failed, but we have to click through to Circle CI to see what the actual failures were.
One thing GitHub does well is the idea of checks. The entire pipeline in GitLab is a binary pass or fail. To see which bits failed, you have to dig into the pipeline.
Would be great to see that (similar to test results) in the merge request, in a similar way that GitHub checks are displayed.
Our typical DevOps set up is Jira for issues, GitHub for source and peer reviews. The pull requests are set up to include a few things like Quality (usually Code Climate), CI (usually Circle CI, sometimes Buildkite), a security auditor, a dependency auditor etc. At the other end, we use a service like Codefresh or whatnot to handle deployment to our environments.
Obviously, GitLab does all this in one ALM, which makes it closer to Azure DevOps than GitHub for direct feature comparisons, so this is more about the source code peer review through merge/pull requests than other aspects of the ALM process.
In GitHub pull requests, when checks fail, we get immediate visibility right on the pull request screen which checks failed, rather than having to go into the pipeline to look at jobs.
From a DevOps perspective, GitLab far exceeds GitHub (obviously). From idea to code, to review to build and publish is great. The pipelines (as I said above) are good.
I'd just like more integration points in the merge request process for external services to augment the functionality provided out of the box, such as Code Climate, Hound, Dependabot, LGTM/GuardRails/Snyk etc. Whilst you can wire these up (kinda) yourself - you could just use rubocop instead of Hound - you don't get the deep merge request integration. When Hound finds a rubocop violation it adds a contextual comment on the pull request at the line of code that is offending. In GitLab with rubocop, you simply fail the pipeline and then trawl through log output.
As I said in reply to sytse above, I think that is the main difference between cultivating a thriving eco-system of integrations vs providing an API and instructions.
There are many products that integrate with GitLab, see https://about.gitlab.com/partners/ There are not as many as GitHub since more is part of GitLab itself. But we're open to supporting anything, even if it competes with GitLab functionality.
Regarding the example you gave for wanting Code Climate. GitLab has similar functionality as a part of the product, it is called code quality and is based on Code Climate engines, see https://docs.gitlab.com/ee/user/project/merge_requests/code_... for more information.
I don't think it's fair to say that GitHub has more simply because it has less built-in functionality as compared to GitLab.
I agree that GitLab has broader functionality than GitHub, but it isn't so broad as to cover the breadth of functionality provided by all of GitHub's integrations combined.
Code Climate is a good example - yes you're right you have builtin quality reports, but setting it up is significantly more complex than on GitHub, and as an example serves to illustrate what I see as the very different attitudes and approaches towards building an eco-system.
Referring to your docs on code quality[1], you need to edit the CI configuration file, understand what a docker-in-docker executor is on runners etc.
Compare this to GitHub's Code Climate integration[2]: single button "Set up a plan" that guides you through s small number of screens and links your account and presto done.
Things that successful marketplaces like Heroku, GitHub, Atlassian, Slack etc get right are the ease with which to add integrations and the seamlessness of the experience.
Single button provisioning, combined billing, single sign-on etc. Just the way GitLab position the idea of integrations makes it seem to me that creating a platform isn't a priority for you (which is totally fine obviously, you're focusing on your priorities, and clearly doing pretty damn well doing so).
GitHub makes their marketplace and integrations front and centre, have extensive developer guides, etc. GitLab's are a bit more... spartan. They're lacking any real spark, they're not inviting. Compare your overview[3] page to the best equivalent I think I could find on GitHub[4]. They're chalk and cheese.
Again this isn't to say GitLab's approach is wrong, its just a different focus.
More specific feedback (and this may have changed since we evaluated it a year ago) a GitLab integration could only perform API actions as a real user of a GitLab account. We wanted to build an integration that would add comments to merge requests, but not be attributed to a real user, but a bot user for the integration. That wasn't (or at least wasn't easily discoverable) possible back then, and was a show stopper for our integration.
Thanks for writing this explanation for how you use DRI. It’s the first time I’ve read about it that went into detail how it supports collaboration and consensus. A few times in the past I’ve tried to explain and ran into problems with the criticism that DRI means authoritarianism. It didn’t help that Jobs was a bigger user of the term.
There is an ongoing effort to get us migrated to latest stable first. So we just upgrade from 5.0.x to 5.1.x https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27480 there are still lots of warnings and deprecations to fix. Rails 5.2 will come next and I believe when we get to the point to migrate to Rails 6 it will be stable already.
There is no plan to ship with unstable/master that I know of.
Has anyone had any luck adding API tests to Gilab's CI/CD pipeline? For some reason I'm able to build Docker images and run them as containers with dind as part of a testing pipeline but I haven't had any luck getting the API test scripts to establish any connection with the containerized service.
This sounds like a Docker networking problem. I would think you need to have docker-compose and bring your microservice and all the dependencies up and then test against your microservice _in the same network_.
I've written some .gitlab-ci.yml files in the last months. What I do is using a script to validate against the Gitlab lint API. This is done every time I save the file.
I also run gitlab-runner on my local machine and test my jobs with `gitlab-runner exec docker`. Don't forget to commit what you need in the job. You don't need to commit the .gitlab-ci.yml, but everything else, because the first step to run the job is cloning the repo.
I have also updated the brew formulas for the last releases of gitlab-runner. Gitlab is great software and I've worked with it and administrated it for the last 5 years. I don't want to miss it.
I was also going to say it's likely a Docker network problem. Docker-in-docker runners work great for us and make it possible to do all kinds testing in the pipeline; for example Selenium, custom REST, OWASP ZAP, etc.
Yes, using docker compose to ensure that all of the containers are connected to each other, or using minikube to simulate deploying a Kubernetes stack.
If your test scripts are running as part of the "before_script", "script", or "after_script" block, they aren't running in the network namespace configured by Docker in Docker and won't have the same name resolution, so you'll need to port map your Docker containers and your test scripts will need to use "localhost" and ports to connect to your containers.
If your tests are themselves run in a Docker container, it should work as expected.
What about just using `docker-compose exec` to get into the running API container, and then executing the tests inside of that, against localhost?
Not as pretty as properly testing from an outside container, but seems by far the easiest way to solve this problem.
I have a test suite doing this. If you can't reach the server by name then try adding an 'alias' to the service definition and then try to connect to that hostname. Good luck!
1) We moved from Gitlab to Phabricator and Phabricator CI sucks so much, we integrated buildkite with it instead
2) We quickly realised that Buildkite UI is superior, but also its runners. You can add custom extensions to Buildkite and make it do whatever you want https://buildkite.com/plugins
Not sure if this is the right place to shed some light on my issue, but my repo is in the process of being deleted for over a month now [0]
Basically I made some mistakes in that repo and didn't know how to rectify them, so I decided to delete it and then make it again. However the deletion process got stuck it seems.
As a counterpoint I prefer the term "merge requests" because I never do 'git pull'. I Always fetch and merge as it gives you more control over the process.
If I call it pull request it would be nice if the gitlab ui would have the same name. I see, you won't change, so maybe offer a config option for this name?
Unfortunately I don't see this being a priority for us, as it would be a fairly large-scale operation for not a lot of benefit. However, you can open an issue for it here if you want! https://gitlab.com/gitlab-org/gitlab-ce/issues
I can understand how their huge success of "built-in CI" quickly leads to "built-in XYZ", but competing with github that lets other companies solve developer/ci problems via marketplace (and now CI via their new terraform actions) may lead to loosing market-leader [my take on their product] position for a code/test/review/merge ecosystem.
[1]: https://about.gitlab.com/2018/10/01/gitlab-product-vision/