Comment by dusanh
21 hours ago
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?
21 hours ago
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