<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
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.
- 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