Updatecli

Caution

Updatecli is an experiment to help keeping infrastructure as much up to date as possible. While a significant effort is done to avoid breaking changes, we can’t guaranty stability.

"Automatically open a PR on your GitOps repository when a third service publishes an updates"

Updatecli is a tool used to apply file update strategies. Designed to be used from everywhere, each application "run" detects if a value needs to be updated using a custom strategy then apply changes according to the strategy.

You describe your update strategy in a file then you run updatecli to it.

Updatecli reads a yaml or a go template configuration file, then works into three stages

1. Sources: Based on a rule, updatecli fetches a value that will be injected in later stages such as latest application version.

2. Conditions: Ensure that conditions are met based on the value retrieved during the source stage.

3. Target: Update and publish the target files based on a value retrieved from the source stage.

Feature

• Flexibility: Easy to define tailored update strategies, you are just one yaml file to it.

• Portability: Easy to add to your workflow whatever it is. Just one command to run. Of course, it’s easy to remove.

• Extensibility: Easy to add new go packages to support more workflows.

Why

They are many projects out there, which can continuously update your files but they all have an opinionated way of doing it and they often want you to adopt a new platform. Building and distributing software is a difficult thing and good practices constantly evolve. Updatecli was built to work independently wherever you need, and combining whatever workflow you are using as you can see in the following section.

Documentation

Documentation for updatecli is available on www.updatecli.io but feel free to look at the next section to get an overview of how updatecli works.

Example

In this example, we define an update strategy in "updatecli.yaml" then we run updatecli apply --config updatecli.yaml. Our objective is to know if the Jenkins project published a new stable version, if they build an appropriated docker image specifically for jdk11 and automatically update our infrastructure accordingly.

## updatecli.yaml sources: default: kind: jenkins spec: release: weekly conditions: docker: name: "Docker Image Published on Registry" kind: dockerImage spec: image: "jenkins/jenkins" targets: imageTag: name: "jenkins/jenkins docker tag" kind: yaml spec: file: "charts/jenkins/values.yaml" key: "jenkins.controller.imageTag" scm: github: user: olblak email: me@olblak.com owner: "olblak" repository: "charts" token: mySecretTokenWhichShouldNeverUsedThisWay username: olblak branch: "main"

What it says: Sources: What’s the latest jenkins weekly version? ⇒ 2.264 Conditions: Is there a docker image "jenkins/jenkins" from Dockerhub with the tag "2.264" ⇒ Yes then proceed otherwise abort Targets: Do we have to update the key "jenkins.controller.imageTag" from file "./charts/jenkins/values.yaml" located on the Github repository olblak/charts to "2.264"? ⇒ If yes then open a Github pull request to the branch "main"

More information here

---

Contributing

CONTRIBUTING

Links

• ADOPTERS

• CONTRIBUTING

• DOCUMENTATION

• LICENSE