ci: Cache postgres volume after first migration

[BYK]

This patch caches all DB volumes based on the sentry and snuba images to avoid doing the same migrations over and over for every test run.

This shaved off a whole minute from "Install self-hosted" jobs (so ~20% speed increase).

Left side: cached re-run -- Right side: no-cache initial run

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.06%. Comparing base (1bb22c0) to head (413b08e).
Report is 1 commits behind head on master.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3488   +/-   ##
=======================================
  Coverage   98.06%   98.06%           
=======================================
  Files           3        3           
  Lines         207      207           
=======================================
  Hits          203      203           
  Misses          4        4           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[aminvakil]

Can we have an env or something like that to punch through cache, I don't think of a reason which someone would need this right now (not using cache), and we can always add it later, what do you think?

On another matter, shouldn't we take postgres, clickhouse version into cache id, so if that gets changed, cache gets invalidated?

[BYK]

Can we have an env or something like that to punch through cache, I don't think of a reason which someone would need this right now (not using cache), and we can always add it later, what do you think?

Don't think this would be useful as this is only happening on CI and changing the cache env variable would require a new commit where we can simply bump the cache key or disable the cache step if we want to.

On another matter, shouldn't we take postgres, clickhouse version into cache id, so if that gets changed, cache gets invalidated?

Don't think so as we should be fine with upgrades too. We still run migrations, upgrade etc. We just happen to start from a warm state which is quite similar to our upgrade test.

[hubertdeng123]

It does not seem like this is intentional? Perhaps

db-volumes-v4-${{ steps.cache_key.outputs.SNUBA_IMAGE_SHA }} ?

[BYK]

Completely intentional. These are prefix matched in order for stale cache restoration. So if we cannot match on both sentry and snuba image SHA, then we fallback to one with sentry image sha regardless of snuba, and finally, it just restores any cache as long as it is v4.

[hubertdeng123]

This is great, wondering how much time this shaves off CI time

[BYK]

This is great, wondering how much time this shaves off CI time

It is in the description 😅:

This shaved off a whole minute from "Install self-hosted" jobs (so ~20% speed increase).