github: fix caching the docker images

[mkmkme]

This PR supercedes #170 and fixes #140

Pull Request check-list

• Do tests and lints pass with this change?
• Do the CI tests pass with this change (enable it first in your forked repo and wait for the github action build to finish)?
• Is the new or changed code fully tested?
• Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?
• Is there an example added to the examples folder (if applicable)?

Description of change

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.25%. Comparing base (fd0e9b7) to head (7683a03).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #176      +/-   ##
==========================================
- Coverage   76.26%   76.25%   -0.01%     
==========================================
  Files         130      130              
  Lines       33970    33970              
==========================================
- Hits        25906    25904       -2     
- Misses       8064     8066       +2     

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

[mkmkme]

Expanded the commit message a bit:

This commit updates the way docker cache is created by including the
current date into the cache key. Now when "save-always" option in
actions/cache is deprecated [1] this seems to be the conventional
way [2] to create the cache.

1: actions/cache#1452
2. https://github.com/actions/cache?tab=readme-ov-file#creating-a-cache-key

Also removed the event_name == 'schedule' check since it doesn't make much sense with the current approach anymore. The cache will be created every day (like it should have been with the original approach). And the old cache will be removed after 7 days of not accessing it according to Github policy: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy

I am especially interested in seeing @smeso review on this PR because you created the original caching approach.

[bogdanp05]

Is it possible the current_date computed here is different from the current_date computed in populate-cache if the pipeline is run around midnight?

[mkmkme]

True, this is possible, and the pipeline might fail because of that

[mkmkme]

It seems like we can't possibly set a global variable of a date. So the only possible way to fix this is to repeat the same "look for cache -> if not found, create one" pattern here as well just because of this corner case and Github limitations :/ That's unfortunate.

[mkmkme]

There are also other options, like:

1. Create cache for each PR instead of tying it with the date
2. Just accept the occasional PR github action failures and restart them manually. It shouldn't happen that often anyways.

[bogdanp05]

I thought it would be possible to create a job to get the date and then just add a dependency to it, at least according to the docs. So something like:

   get-date:
     outputs:
       current_date: ${{ steps.date.outputs.current_date }}
     steps:
       - name: Set current date
         id: date
         run: echo "current_date=$(date +'%Y%m%d')" >> $GITHUB_OUTPUT

and then use it like:

   run-tests:
     runs-on: ubuntu-latest
     needs: [populate-cache, get-date]
     ....
        with:
           path: ./custom-cache/
           fail-on-cache-miss: true
           key: custom-cache-${{ needs.get-date.outputs.current_date }}

I haven't tested this, but if it works, then it would be nice because it abstracts the duplicate "Set current date" step.

If it doesn't work, then I'm happy with option 2. That race condition would happen super rarely anyway and it would work on the next try.

[mkmkme]

Hmmm, thanks, I'll try!