Pre-populate the Sstate Cache folder for the upcoming month

[Satish Mhaske (sampra2025)]

This will help avoid job slowness during the monthly cache setup. On meta-qcom, each build uses a cache from a monthly folder, so on the first day of the month there is no cache for that month and most builds run as clean builds, which takes longer to build the target and can potentially increase stabilization issues as well as cost.

This change will pre-populate the upcoming month folder with the existing cache and clean up cache older than 30days.

[Anuj Mittal (anujm1)]

This will help avoid job slowness during the monthly cache setup. On meta-qcom, each build uses a cache from a monthly folder, so on the first day of the month there is no cache for that month and most builds run as clean builds, which takes longer to build the target and can potentially increase stabilization issues as well as cost.

Can you share more about the stabilization issues? I do not think there should be any issues because of presence or absence of sstate.

Not related to this change, I am wondering why we have monthly sstate directories if we can clean up 'older than 30 days' files in the same directory to save space.

[Nicolas Dechesne (ndechesne)]

This will help avoid job slowness during the monthly cache setup. On meta-qcom, each build uses a cache from a monthly folder, so on the first day of the month there is no cache for that month and most builds run as clean builds, which takes longer to build the target and can potentially increase stabilization issues as well as cost.

Can you share more about the stabilization issues? I do not think there should be any issues because of presence or absence of sstate.

Agreed here. Also the reason why we created a 'fresh' sstate which is empty is to clean up everything at once. So if we make a copy then this is going against the original idea of doing the cleanup.

Not related to this change, I am wondering why we have monthly sstate directories if we can clean up 'older than 30 days' files in the same directory to save space.

the -ctime 30 is here to remove files 'created' more than 1 month ago, to ensure that we delete old files. We've seen cases where the monthly job timed out and left 'old sstate' in there, so they will be deleted 'next' month.

Regardless we should not merge this patch, for 2 reasons:

1. we've learned recently that bitbake is 'touching' all files it is using during a build. so we could largely simplify the sstate management and delete unused files with a single -mtime 15 find command, and removes the 'per month' folder. I believe Jose Quaresma (@quaresmajose) is looking into that
2. Ricardo Salveti (@ricardosalveti) is looking at using S3 instead of EFS, as another alternative

With either 2 or 3 , we don't need this patch anyway.

[Koen Kooi (koenkooi)]

Regardless, please adhere to the commit policy, have a look at CONTRIBUTING.md. The easiest way is to have an agent ingest AGENTS.md and advice you on the commit message.