mudler
commented
5 years ago Correct, we had this previously, now we can just trigger tasks with cache_clean.
For this operation you don't need to actually tag into a namespace, but just wipe the cache and create a fresh one, so it is sufficient to add this in the task:
cache_image: "yes"
cache_clean: "yes"But this is a trick to accomplish that until we have a proper way to handle this.
There is some rough optional protection support in my branch (but lacks still lot of functionalities, things as locks) that should prevent namespace overlaps, by dropping new tasks targeting the same namespace.
I would rather prefer to have in the long run an api endpoint to manage this kind of resources, and how you can prune them, wdyt?
Raising an issue after discussing with @geaaru in #sabayon-dev, Community images are growing excessively. Pre-mottainai we had weekly squashes which would flatten the docker image layers (reducing churn), and monthly cache_clean jobs which would end the chains. Under mottainain, I don't think we have either of these, and images are growing unbounded.
We could schedule a mottanai plan which runs the cache_clean job again, but as there's no locking support that I'm aware of, we could easily get into a race condition where the results of the long-running clean-plus-full-rebuild job get replaced by the next execution of the normal job. I think some locking support in mottainai is needed?