✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: bbf689b. Link to the linter CI: here}

Three comments for reviewers:

1. The actions output of "build scikit-learn" step outputs the ccache statistics at the very end.

2. The Set compiler ID step is an experiment and I am happy to remove/replace if it's not adding enough value. Then the key would be shorter/less specific. Reasoning:

• I have looked at how we define key and restore-keys in build_tools/azure/posix.yml and found doing it the same way is not so useful here. Using something like Agent.JobName doesn't help, because we don't use several jobs that build (lint job doesn't build). Build.BuildNumber doesn't seem to have an equivalent in github actions(?).
• Instead, I have tried to use the compiler as part of the key. ccache then implements one cache per os-compiler combination.
• The Set compiler ID step extracts the compiler from the runner and it gets re-used in the key later. The alternative way using ${{ matrix.compiler }} would mean that we would have the define a compiler on the matrix and we have done that nowhere else, so I assume that we don't want that to keep it more flexible?

3. The cache size is pretty low (I had 6MB after multiple experiments on the other branch), but he have set the maximum size to ccache -M 256M in install.sh. Should it be decreased or would we wait for the other jobs to be added and then re-evaluate this?

can we test this by having another commit and see if cache works?

Nice, it seems to work fine. There may be some tweaks that we can do which I will suggest soon:

• first commit build log, building from scratch takes ~2 minutes:

+ ccache -s
Cacheable calls:    73 / 162 (45.06%)
  Hits:              0 /  73 ( 0.00%)
    Direct:          0
    Preprocessed:    0
  Misses:           73 /  73 (100.0%)
Uncacheable calls:  89 / 162 (54.94%)
Local storage:
  Cache size (GB): 0.0 / 0.3 ( 2.71%)
  Hits:              0 /  73 ( 0.00%)
  Misses:           73 /  73 (100.0%)

• second commit build log, reuses ccache and building takes ~1 minute and you can see some ccache reuse:

+ ccache -s
Cacheable calls:    73 / 162 (45.06%)
  Hits:             71 /  73 (97.26%)
    Direct:         71 /  71 (100.0%)
    Preprocessed:    0 /  71 ( 0.00%)
  Misses:            2 /  73 ( 2.74%)
Uncacheable calls:  89 / 162 (54.94%)
Local storage:
  Cache size (GB): 0.0 / 0.3 ( 2.81%)
  Hits:             71 /  73 (97.26%)
  Misses:            2 /  73 ( 2.74%)

Here is the thinking behind the cache key:

• you can not update an existing cache entry, see doc, so you need to create a cache entry with a different name (and use restore-key to be able to use partial match to reuse a previous cache key)
• we chose to create a new cache entry if there is a "good reason" to, so we added the following files in the hash
  • Cython (including .tp files), C, C++ files (that seems a no-brainer)
  • lock-file. I am not 100% sure about this one, but I guess if the lock-file changes it may be a good enough reason to generate a cache entry e.g. compiler or numpy version change? The ccache doc seems to say that cache will not be reused with a different compiler version (it uses the size and the mtime of the compiler in the hash key by default)
• Azure is creating a cache entry in every build. This was done in MAINT Increase ccache hit rate on Azure Pipelines #22213 to maximize cache reuse. We can always go back to this simpler strategy if we think it's better.

Let's merge this one and adapt if we notice possible improvements to the cache key strategy.