Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thanks for the project, works like a charm #3

Open
pckbls opened this issue Oct 7, 2021 · 1 comment
Open

Thanks for the project, works like a charm #3

pckbls opened this issue Oct 7, 2021 · 1 comment

Comments

@pckbls
Copy link

pckbls commented Oct 7, 2021

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:

(terraform plan) -> (terraform apply)
 ^                   ^
 when: always        when: manual

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:

  1. Always automatically execute (terraform apply) potentially making destructive changes to our infrastructure.
  2. 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

  1. Create a Helm chart that deploys the server into our internal Kubernetes cluster only accessible for Developers.
  2. 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. 😉

@jbergknoff
Copy link
Owner

Wow, I'm glad to hear that this has been useful for you! Thanks for the detailed & thoughtful post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants