Add support for building many/all versions of an alpine package

[osterman]

what

• We need a way to fetch all versions of a package from github and build package

why

• Better continuity of releases

[Nuru]

@osterman This is not a bad idea. We could run a back-fill task, maybe with a date/version count limit so we don't go back too far. We will not get 100% coverage with automation because some apps (e.g. gh) change repos and some apps (e.g. kubecron) change release URL formats, but we should be able to get 90% coverage.

We have the tools to fetch all the release tags and filter them by date, and to build a package for any given release. All we would need to add is a tools to list the package versions we have already released so we do not waste time or cause update issues by rebuilding working packages.

[osterman]

Ya, maybe we could have a VERSIONS file? with all versions to support? Then we can backfill that file and only build versions we cannot fetch from the repo (e.g. issue HEAD requests)

[Nuru]

I think we keep the current VERSION file as the latest we have (or want to build) and continue auto-updating it as we have. Then, separately, we run a backfill task that uses the actual package list from our package repo (which lists all the versions of all the packages we have) and compare it to the list of releases for the package source and build the missing packages. Maybe we run it whenever auto-update detects a new release to make sure we haven't missed any intermediate ones. We can filter the list for pinned packages so that we backfill those properly, too.

[Nuru]

I am marking this as closed by #3503, because although we cannot automatically build all versions of a package, we can now manually build (via GitHub actions) any version that we missed with automatic building, and we have the mechanism to build via scripts on local hosts any set of versions.