12 ms·
interesting. so if i understand this correctly, it's like a bridge between all those little version numbers and hashes in config files for modern infrastructure
by a-dub 5y ago
interesting. so if i understand this correctly, it's like a bridge between all those little version numbers and hashes in config files for modern infrastructure and full scale automation (from running of scripts to provisioning a short lived test environment) for checking if those little numbers and hashes need to be bumped. cool!
- olblak 5y agoKind of, the reason why it's a bit difficult to describe the project is because the different component mean different things to different people. I built updatecli so I could use it to help me maintain infrastructure as code, then bit by bit, I discovered how other people were using it to solve challenges that I didn't imagine. Scenario 1: https://github.com/jenkins-infra/kubernetes-management/blob/main/updatecli/updatecli.d/charts/certmanager.yaml https://github.com/jenkins-infra/kubernetes-management/blob/... We monitor the latest Certmanager chart version available and we bump our git repository so Helmfile can pick the latest version and update our Kubernetes clusters. The purpose is to automate infrastructure as code. Scenario 2: https://github.com/updatecli/website/blob/master/updatecli/updatecli.d/installation.yaml https://github.com/updatecli/website/blob/master/updatecli/u... We monitor the latest Updatecli version so we can update documentation on the website The purpose is to keep documentation up to date Scenario 3: https://github.com/epinio/helm-charts/blob/main/updatecli/updatecli.d/epinio.yaml https://github.com/epinio/helm-charts/blob/main/updatecli/up... We monitor our application so we can automatically release a new version of a helm chart The purpose is to automate the release process.