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

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 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 https://docs.gitlab.com/ci/yaml/#environment> plus <https://docs.gitlab.com/ci/yaml/#dynamic-environments 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-and-manage-deployments/manage-environments 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-environment-scope-of-a-cicd-variable 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 https://gitlab.com/gitlab-org/gitlab/-/environments