31–39 of 39 posts
I like how some are missing the point of the tool because you mentioned (assuming jokingly) that we all love YAML. Anyway, looks really cool. Dependabot seems to some strange limitations, and I'll probably look into using this. Out of curiousity, how are you linked to the Jenkins project? Are you just an OSS contributor or do you do this full time?
I wrote something similar but to keep a local system up-to-date: https://github.com/kdeldycke/meta-package-manager#readme With Meta Package Manager you can aggregate the results of all package managers available on your machine: $ mpm outdated ╭──────────────┬─────────────┬─────────┬───────────────────┬────────────────╮ │ Package name │ ID │ Manager │ Installed version │ Latest version │ ├──────────────┼─────────────…
> Because let’s say it, everybody loves YAML. YAML is everywhere. Nope. Nope, nope, nope. I know a lot of people, including myself, who hates YAML with a passion. First, they hate the format itself. It's very easy to introduce hard-to-find typos. Plus it has multiple versions, no way to tell which one you use, and depending of the parser that ends up eating the file, you may get weird results. It's way worse then jus…
May I suggest creating a JSON Schema for the yaml files, so reasonable editors can help complete the structure? I didn't study the docs to know how much this is on the "ansible" side of things, where conditions can be almost anything , and thus describing possible legal values would be some monster work
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!
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.
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. "Sources": what does this do? Collect information. This doesn't need to be a particular program,…
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.
I wrote something similar but to keep a local system up-to-date: https://github.com/kdeldycke/meta-package-manager#readme With Meta Package Manager you can aggregate the results of all package managers available on your machine: $ mpm outdated ╭──────────────┬─────────────┬─────────┬───────────────────┬────────────────╮ │ Package name │ ID │ Manager │ Installed version │ Latest version │ ├──────────────┼─────────────…
I look forward to trying this with gitea to automatically create pull requests to update ansible plays with the latest version of software.
This looks really cool. How dos it compare to say [renovate?]( https://github.com/renovatebot/renovate ) I look forward to trying this with gitea to automatically create pull requests to update ansible plays with the latest version of software.
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.