KubeRocketCI is an open-source, Kubernetes-native CI/CD platform built on Tekton and Argo CD. It runs entirely on your own cluster and works with GitHub, GitLab, Bitbucket, or Gerrit as the code host. GitLab CI is the CI/CD service inside the GitLab DevSecOps platform. The core difference: Tekton-based CI you own and can isolate, versus CI bound to the GitLab application.
GitLab CI integration in KubeRocketCI lets a single application run its CI pipeline in GitLab CI - on a GitLab Runner - instead of Tekton, while still being managed as a first-class Codebase on the platform. You set one field on the Codebase (spec.ciTool: gitlab), and KubeRocketCI generates a .gitlab-ci.yml in the repository; GitLab then runs the pipeline, with no Tekton involved. From then on, every merge request runs a review pipeline and every merge runs a build pipeline - all native GitLab CI, all on your own cluster.
This is part three of my hands-on series on the local try-kuberocketci testbed. In part one I stood up the full platform in two commands; in part two I built ephemeral preview environments from a feature branch. Both ran their CI in Tekton. This post takes the same kind cluster running KubeRocketCI 3.13 and shows the multi-CI path: how GitLab CI integration works, the three things you must set up before you enable it - a Runner, the onboarded CI/CD components, and a ConfigMap - and a full review-to-build run with real output.