{"id":48192415,"title":"Show HN: Updatecli – A Declarative Update Policy Engine","points":1,"user":"olblak","time":1779193642,"time_ago":"4 hours ago","type":"link","content":"

A few years ago, I came here to share this side project that I was building.

At the time, my problem was simple, I kept forgetting to update files across Git repositories, and none of the tools available to me could cover all my use cases without extensive scripting.

So I decided to build a declarative update policy engine for crafting tailored update workflows.

I needed a way to define, what information to monitor, which files to update, the conditions required before applying changes, and finally a way to push the changes on a Git repository

Whether it was documentation, dependency management, or release orchestration, the goal was always the same.

To stop forgetting updates across repositories.

Back then, I received a lot of great feedback, but I also noticed that people were sometimes confused about how Updatecli differs from Renovatebot or Dependabot. So before going further, let me clarify that point.

Renovatebot and Dependabot are excellent tools, easy to use and requiring very little configuration. I still use them regularly.\nBut they primarily focus on dependency updates, while Updatecli is designed for custom update workflows at the cost of writing and maintaining YAML manifests.

On new projects, I usually enable Renovatebot or Dependabot by default, and then use Updatecli for workflows not supported by those tools.

Here is the link to the previous discussion: https://news.ycombinator.com/item?id=30286047

A few years have passed since then, and the project evolved significantly, thanks to all contributors.

Today, Updatecli can declaratively manage updates across most Git platforms including GitHub, GitLab, Forgejo, etc.

It now ships with 30+ built-in integrations covering:

* structured files like YAML, JSON, TOML, XML, HCL, CSV, Dockerfiles, and arbitrary text files

* package ecosystems including Helm, NPM, PyPI, Maven, Cargo, Go modules, and Terraform

* container registries and OCI artifacts

* Git releases, tags, and branches

* cloud resources like AWS AMIs

* shell scripts and HTTP endpoints for custom workflows

More information on https://www.updatecli.io

One important feature we added is shared policy support.

An Updatecli policy can now be distributed through OCI registries and reuse from different places using an Updatecli compose file.

For example, the following policy:

* ghcr.io/updatecli/policies/autodiscovery/githubaction:0.4.1

Will automatically discover repositories in a GitHub organization and update GitHub Action versions to the latest digest.\nOne use case is enforcing pinned GitHub Action digests across repositories to help reduce supply-chain risks.

  scm:\n    enabled: true\n    kind: githubsearch\n    search: |\n      org:updatecli\n      fork:true\n      archived:false\n    branch: "^main$"\n    limit: 1\n\n

\nThen:

  export UPDATECLI_GITHUB_TOKEN=<insert GitHub PAT>\n  export UPDATECLI_GITHUB_USERNAME=<insert username associated with PAT>\n\n  updatecli diff values.yaml ghcr.io/updatecli/policies/autodiscovery/githubaction:latest\n\n

\nRunning this periodically from CI helps keep repositories compliant with the desired update policy.

Lately, I’ve also been making good progress with a monitoring UI called Udash to visualize Updatecli reports across repositories.\nYou can take a look at https://app.uda.sh/updatecli/ for a public endpoint.

My goal is to quickly assess the update state of projects and understand how automation behaves across repositories.

It’s still very early, but fully open source on https://github.com/updatecli/udash.

Update automation is a surprisingly broad topic, and difficult to summarize in a single post, so feel free to ask any questions.\nI’d also be curious to hear how others here handle large-scale repository maintenance and update orchestration.","url":"item?id=48192415","comments":[],"comments_count":0}