Closed jbergstroem closed 1 year ago
Some info I've collected:
This is how the script would run periodically: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onschedule
One approach to collecting alpine version can be either apk version
if mariadb is installed in said environment; apk info
if uninstalled - both would have to be parsed though.
Another approach is using either their package database or their separate software version monitoring tool
How to materialize a version as well as "template-izing" the Dockerfile
to cater for automated updates is also something that should be managed in the same context of opening a PR.
Some updates as I will attempt this soon:
dpkg --compare-versions "10.4.18-r0" "lt" "10.4.18-r1"
Just had another look at this. We can probably use renovatebot with annotations in the Dockerfile, alongside the repology data source. Much simpler!
Create a timed ci job that checks alpine repos for available versions. This could also open an issue or even a PR should a new version be found.