This is not really an issue but rather a kind thank you for this neat little tool!
Recently my org has decided to turn away from Jenkins and instead unify and streamline our CI pipeline architecture using Gitlab CI. Although we're super happy with the features that Gitlab and Gitlab CI offers, there's one detail missing that we heavily relied on when using Jenkins: For infrastructure related tasks we also make use of Terraform. In the Jenkins world we would execute terraform plan first and if changes are necessary, we used the input() directive to wait for an approval. If no change is necessary, the pipeline would automatically continue without further interruptions.
Unfortunately it turns out that we cannot model the exact same behavior using Gitlab CI's native features. 😞
It is possible to define two consecutively executed jobs such as:
However it is not to possible to conditionally have the(terraform apply) job wait or skip execution based on the result of the previous (terraform plan) job. This gives us two options:
Always automatically execute (terraform apply) potentially making destructive changes to our infrastructure.
Always require an approval even though there's nothing to do which turned out to be highly nonpractical.
Gitlab support told us to try Dynamic Parent-Child pipelines which indeed provide a technical solution for the problem at hand however the resulting user (or developer) experience is also terrible! Luckily after a bit of Googling we stumbled across your little project here. In fact it took us about 2 hours to
Create a Helm chart that deploys the server into our internal Kubernetes cluster only accessible for Developers.
Adapt our existing CI pipeline to leverage the server to have approvals managed by the hosted server
Works like a charm! Not only this makes our CI workflow much more convenient, it also allowed us to simplify our pipeline code by removing weird hacks and workarounds. 🎉
We do have plans to slightly extend the server though, for instance a rudimentary authentication mechanism that gives us the ability to see, who approved a plan. Due to our recently updated and relaxed Open-Source policy we hopefully can contribute something back soon(TM).
If you ever come to visit Germany's Black Forest region, ping us, we owe you a beer. 😉
This is not really an issue but rather a kind thank you for this neat little tool!
Recently my org has decided to turn away from Jenkins and instead unify and streamline our CI pipeline architecture using Gitlab CI. Although we're super happy with the features that Gitlab and Gitlab CI offers, there's one detail missing that we heavily relied on when using Jenkins: For infrastructure related tasks we also make use of Terraform. In the Jenkins world we would execute
terraform plan
first and if changes are necessary, we used theinput()
directive to wait for an approval. If no change is necessary, the pipeline would automatically continue without further interruptions.Unfortunately it turns out that we cannot model the exact same behavior using Gitlab CI's native features. 😞 It is possible to define two consecutively executed jobs such as:
However it is not to possible to conditionally have the
(terraform apply)
job wait or skip execution based on the result of the previous(terraform plan)
job. This gives us two options:(terraform apply)
potentially making destructive changes to our infrastructure.Gitlab support told us to try Dynamic Parent-Child pipelines which indeed provide a technical solution for the problem at hand however the resulting user (or developer) experience is also terrible! Luckily after a bit of Googling we stumbled across your little project here. In fact it took us about 2 hours to
Works like a charm! Not only this makes our CI workflow much more convenient, it also allowed us to simplify our pipeline code by removing weird hacks and workarounds. 🎉
We do have plans to slightly extend the server though, for instance a rudimentary authentication mechanism that gives us the ability to see, who approved a plan. Due to our recently updated and relaxed Open-Source policy we hopefully can contribute something back soon(TM).
If you ever come to visit Germany's Black Forest region, ping us, we owe you a beer. 😉