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.
