I am using GitLab in my work environment and I really try to embrace it. But some features one just expects from a basic Jenkins setup are either missing or weirdly implemented and feel like duct-taped into GitLab.
Take for example:
- Code coverage reports:
You can have one absolute number to get your total coverage. To get the number you have to provide a Regex deep down on the main project settings. This Regex has to match some log output of your CI job in order to be picked up, e.g “Total 87%”.
Why can’t GitLab collect cobertura Test reports for example?
to circumvent the above downsides, you can get creative, and generate HTML websites of the Unit test and Coverage reports themselves and publish them somewhere. An ideal place would be GitLab pages.
But you are only allowed to have one publish job for GitLab Pages. And this publish job has to have a special name so it is recognized for publishing GitLab Pages. The artifacts you want to publish have to be in a special named folder in order to publish them. So you fallback to some hackery by using “mv,mkdir”
These were some examples which I find not that exotic for a CI setup and I know from previous experience that Jenkins handles all these with ease.
To circumvent this shortcoming, we introduced SonarQube.
I feel that people often are drawn to a shiny, small GitLab CI yaml and are happy to get started so fast.
But again having Jenkinsfiles with shared libraries, which you can program in Java and Groovy, is superior to the next yaml include/extend you are going to add.
My 2cents are that:
If you are a solo developer or a small company Gitlab might be fine for you. When your company is larger and you want to be able to share knowledge using shared libraries, have a streamlined CI setup with GitLab includes from multiple departments, GitLab gets tough.
How could one be confident to use for example their 1-click deployment (autodevops) Feature if the implementation of CI basics like collecting test results and coverage reports have this weird taste to it?
I wish these features will get better and please don’t take this too harsh. My tone might sound worse than it is.
GitLab Product Manager here. I really appreciate the feedback on those features and it helps inform some upcoming work to make them better. The team is currently working on improvements to JUnit parsing (https://gitlab.com/groups/gitlab-org/-/epics/2854) so we can enable those Junit reports by default.
We are also working on the next set of code coverage features to build this category out further and would appreciate any input you might have on the issues there as we're prioritizing and scheduling for the next few milestones (https://gitlab.com/groups/gitlab-org/-/epics/100).
Take for example:
- Code coverage reports:
You can have one absolute number to get your total coverage. To get the number you have to provide a Regex deep down on the main project settings. This Regex has to match some log output of your CI job in order to be picked up, e.g “Total 87%”.
Why can’t GitLab collect cobertura Test reports for example?
- Unit Test Results:
Collecting JUnit test results is disabled by default, since there is a warning about a performance issue when collecting them https://docs.gitlab.com/ee/ci/junit_test_reports.html#enabli...
- collecting multiple artifacts as HTML pages:
to circumvent the above downsides, you can get creative, and generate HTML websites of the Unit test and Coverage reports themselves and publish them somewhere. An ideal place would be GitLab pages.
But you are only allowed to have one publish job for GitLab Pages. And this publish job has to have a special name so it is recognized for publishing GitLab Pages. The artifacts you want to publish have to be in a special named folder in order to publish them. So you fallback to some hackery by using “mv,mkdir”
https://about.gitlab.com/blog/2016/04/07/gitlab-pages-setup/...
These were some examples which I find not that exotic for a CI setup and I know from previous experience that Jenkins handles all these with ease. To circumvent this shortcoming, we introduced SonarQube.
I feel that people often are drawn to a shiny, small GitLab CI yaml and are happy to get started so fast. But again having Jenkinsfiles with shared libraries, which you can program in Java and Groovy, is superior to the next yaml include/extend you are going to add.
My 2cents are that:
If you are a solo developer or a small company Gitlab might be fine for you. When your company is larger and you want to be able to share knowledge using shared libraries, have a streamlined CI setup with GitLab includes from multiple departments, GitLab gets tough.
How could one be confident to use for example their 1-click deployment (autodevops) Feature if the implementation of CI basics like collecting test results and coverage reports have this weird taste to it?
I wish these features will get better and please don’t take this too harsh. My tone might sound worse than it is.