ci: build-yocto: cleanup sstate-cache after the build

[quaresmajose]

We need to clean up the ci local sstate-cache that is not used, otherwise it will grow infinitely.
This will take up significant space that will not be used by anyone since invalid sstate-cache
artefacts will no longer be needed.

Fixes #715

[doanac]

not sure how long this script will take. My past recollection makes me think this will be pretty slow. Have you considered doing this on a cron schedule instead so that it doesn't affect day-to-day stuff as much?

[ndechesne]

Yocto docs about sstate-cache-management says

It has the ability to purge all but the newest cache files on each architecture, and also to remove files that it considers unreachable by exploring a set of build configurations. However, this command requires a full build environment to be available and doesn’t work well covering multiple releases.

Which is not very encouraging to be honest..

[quaresmajose]

for this first run it takes about 15 minutes for each machine but note that we have a very big sstate folder since it has never been cleaned yet. I expect to get much less time after this first interaction

[ndechesne]

We should run it on push event only, not PR. First it would run less often, and then we really care about sstate for metadata which is merged, not what's in a PR which is temporary.

[github-actions]

Test Results

 3 files  ±0   6 suites  ±0   1m 57s ⏱️ ±0s
23 tests ±0  23 ✅ ±0  0 💤 ±0  0 ❌ ±0 
57 runs  ±0  57 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit 18ba973. ± Comparison against base commit da66ef2.

♻️ This comment has been updated with latest results.

[github-actions]

Test jobs for commit 2b1b5e2

• Job 68213 on qcs9100
• Job 68212 on qcs6490
• Job 68214 on qrb2210-rb1

[quaresmajose]

We should run it on push event only, not PR. First it would run less often, and then we really care about sstate for metadata which is merged, not what's in a PR which is temporary.

Good point! I have changed it to just run on git push events.

[github-actions]

Test jobs for commit 47b7c1d

• Job 68229 on qrb2210-rb1
• Job 68228 on qcs9100
• Job 68227 on qcs6490

[github-actions]

Test jobs for commit 18ba973

• Job 68238 on qcs6490
• Job 68237 on qrb2210-rb1
• Job 68239 on qcs9100

[koenkooi]

When I looked at clean-sstate-cache a few years ago, it would remove everything unrelated to your existing build, so it would delete sstate for all other machines. Does it still do this or has it become smarter?

[quaresmajose]

When I looked at clean-sstate-cache a few years ago, it would remove everything unrelated to your existing build, so it would delete sstate for all other machines. Does it still do this or has it become smarter?

I believe the script is smart enough to support builds with more than one machine but I'm sure it will be like that. I will need to test this locally on my machine to actually see what it deletes.

[lumag]

We should run it on push event only, not PR. First it would run less often, and then we really care about sstate for metadata which is merged, not what's in a PR which is temporary.

I'd go for a scheduled cleanup, e.g. once a week or so.

[ndechesne]

that would indeed work better. even once a month.. but that also means we need to duplicate the build config/machines in that cleanup job, since we need to inherit the same matrix config, right?

[lumag]

Can't we define machines in a common config file which gets included by both workflows?