olblak

Disclosure as I am working for SUSE on Rancher.

It's Kubernetes in Kubernetes and a reference in k3s which is also a project we are heavily contributing to, at SUSE.

Thanks for sharing

Updatecli focus on dependencies which can't be easily identified based on the context. Hence the need to describe how to retrieve an information and then what to do after with it.

And then once you have the latest version, you also have the challenge to know how to apply that update.

More I dig in the dependency management topic, more I realize that we still have long way to go.

> I like the idea of automatic proposed changes triggered by external events, but I'm not sure a monolithic tool with plugins is the best way of going about it. The Unix way to solve this problem would be to decompose your program into a couple of different programs that just do one thing, with flexible inputs and outputs.

Waow, thanks a lot for you feedback, especially to take the time to write this down. I'll do my best to answer as you cover different topics which have been scratching my head since the beginning of the project. But first keep in mind that I had a strong constrain which was my spare time :).

It's definitely something which I am planning to improve.

Currently everything is done at build time and rely on Golang interface. So a resource kind need to match a golang package. A package needs to implement the correct function for it to work. for example for a "source" you need to implement the "source" function as in the following example.

``` func (m *Maven) Source(workingDir string) (string, error) { // Implement whatever you need and return the source value return "the source value", "an error if needed" } ``` Like in this package https://github.com/updatecli/updatecli/tree/main/pkg/plugins...

And the matching between a package and a resource kind is done here https://github.com/updatecli/updatecli/blob/main/pkg/core/pi...

Ideally I would like it to be done at runtime similar to Terraform.

If needed you can still use the "shell" target but then you put a strong dependency on the tool used within your script. Let say that your script call a python tool, then you need to be sure that both your local and ci environment have the same python version. I personally consider it as a fallback when I don't have the time to implement something better.

Ideally I would like to be able to use resources which are very specific to environment and therefor not suitable for everybody.

Kind 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/...

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/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/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.

Thank you for the feedback. So If I understand you correctly, you suggest to improve the feedback loop when writing updatecli configuration from an IDE.

I worked for 5 years at CloudBees within the community team so maintaining the infrastructure project was one the things I worked on https://GitHub.com/jenkins-infra

updatecli supports both

To add on top this. I started by supporting other DSL such as Json. Then I realized it was adding burden on me in terms of documentation since people would ask me for different examples.

Cluelang is a DSL which I already considered and that I like very much. It wasn't high enough in my priorities.

I struggled to use the HCL.

The DSL used by updatecli is not fixed in stone. It's just the interface exposed. The reality nowadays, is that YAML remains the most used DSL.

Thanks, Feel free to open GitHub issue on https://github.com/updatecli/updatecli/issues was what you were looking for. That would be very useful

You need very good tests in place to automatically change something or a lot of trust in your dependencies :P.

It's not the case on most of my project, so I never commit directly to the main branch, instead I commit on a temporary branch then open a PR on GitHub so we just review and merge the changes.

Thank you very much. Major difference with dependabot is that you can use it for more use cases as you define what, how, and when something should be updated