Comment by mdaniel
1 day ago
In my experience, the "really good" is that it comes batteries included:
- completely docker based CI/CD which makes reasoning about what it's going to do easier than "read through some minified .js from some rando"
- they do have composable CI/CD akin to the GitHub Actions marketplace, but I haven't used it as much in anger to speak to how valuable it is versus "competitive checkbox feature"
- built-in Terraform State, so no more S3 + Dynamo
- highly configurable JWT claim curation for ease of OIDC based access from the pipelines
- good integration between the platform and multiple Kubernetes clusters
- related to that, a strong "review environment" setup
- they were also hinting at being a Sentry replacement, but regrettably I had to switch back to GitHub before that came out of preview so I don't this second know where it stands
GitLab doesn't have an equivalent of GitHub actions (except an alpha-quality prototype).
GitHub Actions can share runtime environment, which makes them cheap to compose. GitLab components are separately launched Docker containers, which makes them heavyweight and unsuitable for small things (e.g. a CI component can't install a dependency or set configuration for your build, because your build won't be running there).
The components aren't even actual components. They're just YAML templates concatenated with other YAML that appends lines to a bash script. This means you can't write smart integrations that refer to things like "the output path of the Build component", because there's no such entity. It's just some bash with some env var.
I can map most of the list but I can't recall what would be the "review environment setup" What did you mean by that?
Pedantically I think GLCI treats every environment the same, but by review environments I meant "disposable copies of the app such that one could interact with it during merge request review" e.g. https://mr-8675.example.com corresponding to /example/-/merge_request/8675 that would be provisioned when the MR was opened and torn down when the MR was merged or closed
<https://docs.gitlab.com/ci/yaml/#environment> plus <https://docs.gitlab.com/ci/yaml/#dynamic-environments> et al
I believe it aligns with this behavior in GitHub: <https://docs.github.com/en/actions/how-tos/deploy/configure-...> with the distinction that it appears from the GH docs that they think of that as "needs administrative approval" whereas GLCI thinks of it as "if the pipeline has permissions to run provisioning, off to the races, because names are free"
GitLab introduced the "deployment tier" I think as a means of communication to other users about the importance of the environment, but control over what credentials were made available to CI/CD was always controlled via <https://docs.gitlab.com/ci/environments/#limit-the-environme...> which partially explains why the only reason to involve a repository administrator would be to install or update a secret needed to deploy successfully
---
it the spirit of "they really, really drink their own champagne," one can see the environments for GitLab itself https://gitlab.com/gitlab-org/gitlab/-/environments