If you know a bit about GitLab and Docker, GitLab CI is pretty easy to grok. I really enjoy that you can run your CI jobs inside any old Docker container (with a shell). GitLab CI is built up from very simple concepts and functionalities, but still enables some powerful use-cases.

The artifacts feature is great and some artifacts, like unit test report files, can be interpreted by GitLab and used in various parts of the GitLab web UI. A lot of this just works and most of the CI features are available in the GitLab community edition which is open source.

I have not used Jenkins actively since before the Jenkins pipeline file format was common. So for me Jenkins always appeared to be this game of checking the right checkboxes and clicking the right buttons in the Jenkins UI. The new pipeline feature is probably much nicer. However, now that I use GitLab I don't really see any reason to switch back to Jenkins.

(Disclaimer: CloudBees cofounder here)

Our hope to simplify away the checkboxing and plugins is ready to go distro (free of course): https://www.cloudbees.com/products/cloudbees-jenkins-distrib...

You mention docker and it is super great for CI: it’s probably one of the widest used feature of Jenkinsfiles (you can specify what image or dockerfile you want a stage to run in - simple but powerful, as you probably know)

Good to hear CloudBees seems on top of this issue. Seen multiple posts of you guys here :)

Last I checked, there were a lot of little things that made it not possible to move to GitLab CI. E.g.:

- Can't customize your git checkout process (e.g. shallow clone with depth, or merging source branch with target branch with certain strategy)

- Can't make job run/not run based on filter on source branch/target branch/etc. of a merge request

- Can't dynamically make certain jobs only run on certain agent machines

So I'm still stuck with Jenkins for now. I know we love bashing Jenkins but I have yet to come across anything that offers the same amount of flexibility.

You can definitely do all of your requirements, but likely as a result of recent features

1) you can customise the git checkout depth and style: https://docs.gitlab.com/ee/ci/yaml/#shallow-cloning https://docs.gitlab.com/ee/ci/yaml/#git-strategy

2) https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic

3) https://docs.gitlab.com/ee/ci/yaml/#tags

I'm not associated with gitlab at all but happy to give pointers if anyone wants to contact me direct

2) was released in October, about six months ago [0]. I'd also like to add: as a user of GitLab for about a year now, their steady rate of feature releases has bene pretty pleasant, even if I can't take advantage of some right away.

[0] https://about.gitlab.com/2018/10/22/gitlab-11-4-released/#ru...

I'm not sure that's what I needed. For example, I wanted to trigger a job only for a merge request, and only if the target branch of the merge request is e.g. master. Is that possible? Trigger a job only for a MR is possible, but I don't know how to further do the later branch filtering.

When using a merge_request pipeline, GitLab defines additional variables for the run. That includes `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`.

So it would look something like this:

  job:
    only:
      refs:
        - merge_requests
      variables:
        - $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

Oh wow I didn't know you can do conditionals with variable like that. I'll give it a try later, thanks!

We generally only merge into master at my org, but I didn't know you could conditionally trigger jobs using an equality expression on a GitLab-provided variable. I'll have to keep this in the back pocket for future reference, thanks! Any docs that describe this feature in more detail?

I will second this, Gitlab has the best CI I've ever used, and I don't know what it is. The UI is just so clean, it does what I need to and is easy to configure. I put all my projects on Gitlab mostly because of the CI, but also because of the other great features.

GitLab product director for CI/CD here - thanks so much for the feedback, everyone. It's really great to read how much you're getting value out of what we built.

We have an overall CI/CD direction page up at https://about.gitlab.com/direction/cicd which you can drill down into the individual stages plans from. Feedback is always welcome, we love building things in partnership with real users. You can reach me at [email protected] any time.

Have you started working on providing a UI for the XML test result artifacts produced in CI runs?

They are displayed in merge requests but not anywhere in the normal CI pipeline UI and I'd live to be able to see those and see what works and what doesn't.

GitLab Product Manager for Verify (CI) here (who works for the Director above ).

Yes - that's something we want to get to this year. We call it "CI Views" right now but we want to expose better all the types of test results that get collected by GitLab. Today for XML (JUnit) results, you can see what fails in the merge request with https://docs.gitlab.com/ee/ci/junit_test_reports.html.

But we want to make the XML, JSON or HTML output of _any_ type of test first class with CI Views: https://gitlab.com/gitlab-org/gitlab-ce/issues/35379

Yes, but that only works for the merge request view so far, are there plans to add a view of these to each CI job, so even if something on master fails, I can see the results?

Not sure if it will make the first iteration (as merge request centric workflow will be "first")...but I agree the vision should include the ability to see the tests on any pipeline.

I haven't checked out Gitlab in a long time. My, they've come a long way! I love a lot of what I'm seeing including the Web IDE and their bias towards making CI/CD a priority.

Inclusion of the free docker registry was also pretty visionary, and it's been a while since they added that -- it's crucial for just about all my new projects.

I'm the GitLab product manager for the Package, which includes the container registry. Thanks for the feedback! You can see the updated vision and direction for the container registry here: https://about.gitlab.com/direction/package/container_registr...

If you have any questions or feedback, you can email me at at [email protected]. I'd love to hear more about how you are using the docker registry today and any improvements you'd like to see made to the product.

Just saw this, thanks for the link to the vision! I can't say I have any great recommendations for the container registry but hopefully someone that does sees this.

NO debug overs ssh, why I still use CircleCI.

GitLab Product Manager here

I'm not super familiar with Circle CI's SSH debugging, but we do have a feature called "Interactive Web Terminals" https://docs.gitlab.com/ee/ci/interactive_web_terminal/.

This allows you to connect to a terminal in the running job on GitLab CI for debugging. Would love to understand how this does or does not meet your use-case here.

Great, seems it does the job. 'Cause sometimes 'test passed'/'test failed' isn't enough, you should go deeper.

CircleCI supports SSH connection for max 2h, then shutdown the task.

Is Gitlab CI available as standalone solution? I don‘t need a source code solution, just an CI solution.

If you prefer to host your code on GitHub, it is fine! You can use GitLab CI/CD the way that you host your code on GitHub, but build, test and deploy from GitLab. Take a look at https://about.gitlab.com/solutions/github/!

This is not a full standalone mode, because GitLab CI is a built-in solution that can not be easily separated, but might work for you.

Multirepo pipelines behind a paywall is a good reason to say "No, thanks".

TBH, its easily done in shell via REST API. We use custom pipeline runner from simple Powershell scripts that works even better for us then default style.

We set all jobs to manual and then our script triggers them depending on commit message, person, moon phase etc.

But really, this should be in core. Its very hard to do multirepository stuff. Its not that easy to do mono repo stuff too - I really need a pipeline withint sub-project, a mother pipeline, option to run whatever one I want etc... Gitlb pipelines could be a lot better.

I find it very easy to make multi-repo stuff, I've also wrote about it: https://vadosware.io/post/fun-with-gitlab-ci

Also, running pipelines in different projects and whenever you want is accessible from the web interface... It could be cleaner, but IMO adding even more syntax to the YAML file can also be a rabbit hole -- CURL from the script section seems like not a bad middle ground.

Am I misunderstanding what is being referenced?

This post seems very focused on projects with just a single developer. The "recognizing and tagging" versions for example completely breaks down when you have multiple people commit and merging things to master and multiple pipelines running that are trying to recognize and tag versions.

The post is very much not complete -- there is much more a team would have to standardize to fully take a set up like this into production, bu I'm not sure that it "completely breaks down" with more people contributing.

As long as there is some release coordination, a system like this can work. In particular, I've found that the lightest way to get a system like this working for x > 1 developers is to have a release-vX.X.X branch for releases that are going out and vX.X.X tags for releases once they have actually landed.

You mention the recognizing and tagging versions being an issue -- are you imagining a world where two people are releasing something at the same time? I'm not exactly sure

If we assume that what that posts suggests isn't feasible, regardless of how you deploy and do your CI, if your release process can be done by a human, it can likely be automated. Gitlab CI is most robust and yet easiest to understand automated CI system I've seen for making that happen (at least that was my intended point).

This is what interests me a lot.

I have found that there are moments that start to give chaotic behavior in CI that are influenced by the number of people working on mono repository and some other stuff like code maturity: 1 dev, 2-5 devs, 5-10 devs and 10+ devs .....

Something that works great for any number might start to break for other number. Something effective for huge team may be very bad for smaller team. Something that works great in one moment (first several months of the project when thing still get shape 0.X.Y versions) sux when we move to 1.x version and vice versa.

I am not aware of anybody giving more detailed thought about this nor examine what could be most optimal solution for any type of team (if such thing exist) or on what precise moment you start doing certain practices (for example protecting master branch).

I know about this way, but it's basically building CI upon CI, doesn't sound good from any perspective.

Multi repo pipelines are not paywalled? I can have one repo trigger jobs in another today, I've written about it a little bit: https://vadosware.io/post/fun-with-gitlab-ci/

Am I misunderstanding what you meant?

Answered to other sibling comment, could elaborate further for you though.

In order to pull other pipelines through Gitlab's API, you have to build another CI on top of an existing one. What I mean is that you're making the a pipeline to handle projects, but there's a catch - you have to run another pipeline to set the variables in the One pipeline to rule them all because you can't override variables from the jobs themselves! And the main pipeline would run a bunch of scripts to pass variables and handling the state.

Now let's compare that to other systems from my experience. Jenkins way: one Groovy script (might be written as a special job type from UI or through VCS) to do the job with some fancy features like pause to confirm the next step from the CI's Web UI, full control of everything. Teamcity way: either could be made from UI (with reverse dependency chain because you need to start connecting pipeline from the last jobs to first) or write yours from scratch with Kotlin DSL (there's still no direct support for pipelines[1]), you can handle the process through dependency settings and by setting variables from the jobs themselves. [2] An example of Teamcity approach. (black boxes are there because of my NDA)

[1]https://blog.jetbrains.com/teamcity/2017/02/kotlin-configura...

[2]https://imgur.com/a/jkid47J

edit: added picture.

edit2: added link to TC blog and rewrite the link to a screenshot.

GitLab Product Manager for Verify (CI) here.

This is really valuable feedback, thank you for it. It's something we are thinking about and working on fleshing out a vision for. Two epics we have around these ideas include [1] Making CI lovable for monorepos and [2] Making CI lovable for microservices.

Both of these challenge our current assumptions around the project::pipeline relationship and will help make room for improvements around that model and provide flexibility to build more complex models that work for "real world" problems like the ones you've stated. However, I don't believe we have all the answers yet so I would love more feedback on these and the issues attached.

[1] https://gitlab.com/groups/gitlab-org/-/epics/812

[2] https://gitlab.com/groups/gitlab-org/-/epics/813

Thanks for clarifying, I see exactly what you mean now. It looks like some Gitlabbers are in this thread now so hopefully they see this as well

what is your alternative please ?

In one of the previous jobs I've used Jenkins Pipelines (and oh boy it was PITA to set it up in 2016) to handle jobs of different projects. On current one we are using Teamcity (still cheaper than Gitlab Silver license for us) which has the support of this feature as long as branch names have a common variable in their naming convention.

I.e. Project1 has branches in form feature/TICKET_NAME or fix/TICKET_NAME, Project2 uses only TICKET_NAME, TeamCity VCS settings are based upon masks of branch names so ticket 12345 would be branch 12345 in P2 but fix/12345 or feature/12345 of P1 if one exists (priorities could be tweaked too).