Provide a way to check for upgrades

[smira]

Be "smart" here, potentially handling different layouts of download locations (e.g. http file server, GitHub releases, etc.)

Run something like bldr check-versions and receive output similar to:

NAME    VERSION   UPGRADES
make      2.18.1         2.18.2, 2.19.0

Small issues:

• [x] Version can't be extracted from https://github.com/opencontainers/runc/releases/download/v1.0.0-rc95/runc.tar.xz

[andrewrynhard]

Would love this. Any idea on the implementation yet?

[smira]

I thought about something really simple, in general download URLs seem to be one or another format:

• http://host/some/path/package-$version.tar.gz
• http://host/some/path/package$version/package-$version.tar.gz
• GitHub/other release management

So if we analyze the structure, do listing on appropriate level and parse back versions, we can provide something readable. It won't be 100%, but probably 99%

[andrewrynhard]

I thought about something really simple, in general download URLs seem to be one or another format:

• http://host/some/path/package-$version.tar.gz
• http://host/some/path/package$version/package-$version.tar.gz
• GitHub/other release management

So if we analyze the structure, do listing on appropriate level and parse back versions, we can provide something readable. It won't be 100%, but probably 99%

Yeah I think that is acceptable.

[AlekSi]

One thing that is required for proper implementation is the ability to load all packages with all steps independent of templating and everything else. (Kinda like Go linters should load Go code ignoring build tags.) For example, u-boot update is not reported on my machine due to https://github.com/talos-systems/pkgs/blob/d779204c0d9e9c8e90f32b1f68eb9ff4b030b83c/u-boot/pkg.yaml#L16

[smira]

I wonder if we should do templating still, but provide a set of values to test the upgrades with, and merge/deduplicate the results. E.g. go is built in different way on arm64/amd64.