Add support for risc-v (and plan for platform addition in general)

[brandond]

We are working in the background to add risc-v support to k3s at k3s-io/k3s#7151. However, one of the challenges of this effort is lack of risc-v platform support in rancher-mirrored images.

While we could simply add this to the arch list, this would change the multi-arch digest for any tags that we currently mirror that have this platform available. We should figure out how to add this platform to only new tags, in a way that is minimally disruptive to the list maintenance process, and can be reused when adding new platforms in the future.

One possibility would be to

1. Add a new config file that tracks platform:start:end - where either or both start and end may be unspecified to indicate minimum and maximum values for the respective options.
2. Existing platforms would be listed with an empty start and end date.
3. Use the output of git blame --date=unix images-list to determine when an entry was added
4. Add the platform to the list to be mirrored if the entry is newer than that platform's start date, and older than the end date

Note that we are evaluating when the entry was added to the list, NOT when the entry was published to the source registry. This approach should work as long as we continue to not modify existing list entries, such that git blame properly indicates the correct date for the addition of the entry.

[brandond]

cc @superseb for thoughts

[superseb]

Seems like the same issue as in #379 (comment), where we want to switch to sync all archs. First question to be answered is if we want to mirror archs that we don't "support" (if we want to combine efforts).

If yes, we can sync all archs and use a simpler approach like copying the current images-list at the moment we switch to determine if the image/tag needs the old or new approach.

If no, we need something as described in this issue. We could still simply copy the current images-list to images-list-before-risc and compare in the script if it's new or not. But I assume that having duplicated lists might not be what we want?

[brandond]

Yeah I guess just mirroring all would be fine; I'm honestly not sure where the requirement to selectively mirror platforms came from, or if we need to retain it. I'd love to avoid creating multiple copies of the image list if at all possible; can you think of any pitfalls to using git blame to identify the entries that should observe the new behavior?

If that's not reliable (and I'm concerned it might not be) then perhaps we could just add a new optional field to the end of the list that would enable the new platform mirroring behavior.

[superseb]

We can easily trial this, but I think it will be fine. What is the concern? I think we could actually just use that as the method to move to syncing all archs.

Running a quick test with a bash one liner on the current images-list and a randomly chosen epoch, I get good results on what images need old and new logic. If you can share the concerns I can test it some more.

[brandond]

I guess I'm just concerned that using blame ties us to being exceptionally careful about never modifying existing rows. If something gets accidentally touched by a newer commit, it'll get promoted up to all arch. As long as we're careful I guess it should be ok.

[superseb]

If we add a CI check for modifying existing rows as part of this, it should be good.

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[brandond]

unstale. @superseb are you up for this, if not I'll take a shot.

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[brandond]

Bad stalebot.

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[brandond]

still in the backlog

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.

[brandond]

no

[henryys]

unstale. @superseb are you up for this, if not I'll take a shot.

hi，brandond, i'm very care about this method，How is the progress of this adaptation work？

[github-actions]

This repository uses an automated workflow to automatically label issues which have not had any activity (commit/comment/label) for 60 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the workflow can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the workflow will automatically close the issue in 14 days. Thank you for your contributions.