Reduce the amount of duplicated code in hack #3447
Comments
AkihiroSuda
added
kind/refactoring
|
I still think it would be easier to handle the images separately from the templates, but that's a different topic... For now, we just have to replace the Another thought, should the "latest" images be marked in the list somehow - instead of just by missing a |
I would much prefer if we can keep the languages in the project to just bash and Go, if reasonably possible. I always thought the image updater should have been written in Go, but since I was not spending my time on it, it seemed fine to let somebody else write it in bash.
The updating can easily be done using ❯ yq '.images[0].location="https://example.com" | .images[0]' templates/default.yaml
# Try to use release-yyyyMMdd image if available. Note that release-yyyyMMdd will be removed after several months.
location: "https://example.com"
arch: "x86_64"
digest: "sha256:c2c3ed89097c5f5c90ebbe45216d1569e3ea2d3c8d0993eeae74f859f6467cdb"This can be done by running |
|
@afbjorklund @jandubois Can I pick this ? |
Fine with me, but please discuss first how you would implement, and only start writing code once there is agreement. My ideas are that there should be some generalized update logic, and then specific updaters for each distro. The distro updaters are each in a separate Go package, and "register" themselves in an The general updater will then process all templates passed to it on the commandline and will give each registered updater a chance to update each image. The updater would either decline (next updater gets a chance), accept without a new image (stops checking this image because no update is available), or return the new image/digest. The general updater will then update the template with the results. But feel free to ignore if you have a better idea. |
|
@jandubois, as far as I understand, many updated scripts need to be written in Go. We can generalise some business logic in some places (Base) , and there it can be inherited by scripts. This is my current understanding. I have to go through your approach more clearly. |
|
You could try a high-level proof-of-concept with a single distro, to show the direction you want to go. I'm just trying to make sure you are not spending a lot of time on all the details before we have agreement on the general design. I don't actually care too much about the details as long as it is modular and can easily be extended to cover additional distros without duplicating any code. |
|
Some variables and function renaming would work as well, it is not so much the duplication but the little differences. But I do think it should be possible to configure the images as configuration, without having to write code for each... |
|
The code can get more complicated (for the "helper" functions), as long as the config gets simpler (for the future updates). So the names and the regexes could be configured in a file, and then the code could parse that and run the updating? But the "configuration" can be bash to start with, and just move more functions into the |
Description
Currently there is an almost identical copy of the update script, for each distribution.
These should be made into a program with config instead, to share common functionality.
It would probably be better to convert them from shell scripts into a language like Python (or Go).
The current scripts are hard to write and test, and don't really have any unit tests (only functional)
It also fails on older platforms, due to not checking the versions or the functionality of the tools.
The text was updated successfully, but these errors were encountered: