CI: enable caching for openssl-master, libressl-master, and aws-lc-latest

[junaruga]

This PR is a follow up by #1108, enables caching for openssl-master, libressl-master, and aws-lc-latest by removing these excluded conditions. Note there is no actual running libressl-master case in CI. I just removed the libressl-master condition.

In my fork repository's test, I confirmed the actions/cache caches the openssl-master and aws-lc-latest. The logs are below.

https://github.com/junaruga/ruby-openssl/actions/runs/34124430593/job/101749642583#step:3:4

Run actions/cache@v6
  with:
    path: ~/openssl
    key: openssl-Linux-openssl-master-default
    enableCrossOsArchive: false
    fail-on-cache-miss: false
    lookup-only: false
    save-always: false
Cache not found for input keys: openssl-Linux-openssl-master-default

https://github.com/junaruga/ruby-openssl/actions/runs/34124430593/job/101749642675#step:3:4

Run actions/cache@v6
  with:
    path: ~/openssl
    key: openssl-Linux-aws-lc-latest-default
    enableCrossOsArchive: false
    fail-on-cache-miss: false
    lookup-only: false
    save-always: false
Cache not found for input keys: openssl-Linux-aws-lc-latest-default

Commit message

Remove the condition that excluded these builds from caching. Caches not accessed within the last week are evicted according to the actions/cache documentation, so the cached build is at most about a week old, which is acceptable for these builds.

https://github.com/actions/cache#cache-limits

Cache Limits
A repository can have up to 10GB of caches. Once the 10GB limit is reached,
older caches will be evicted based on when the cache was last accessed. Caches
that are not accessed within the last week will also be evicted.

Assisted-by: Claude:Opus 4.6

[rhenium]

Thanks!

[junaruga]

Thanks for your review!

[junaruga]

@rhenium Sorry. I noticed that the "Caches that are not accessed within the last week will also be evicted." means if we access (use) the cache once a week for example, the cache is not evicted (removed) permanently, right? If that is true, I think we need to revert this PR's commit.

[junaruga]

Good news. I found that the way to include the string generated by date command for the cache key. As the %W means a week number of year, we can include date -u '+%Y%W' to the key to expire the cache within 7 days.

https://github.com/actions/cache/blob/3edfce9056124e459a23f683a21433670d47daca/README.md?plain=1#L248-L262

$ date -u '+%Y%W'
202636

$ man date
...
       %W     week number of year, with Monday as first day of week (00..53)
...

What do you think? Do you want to apply this commonly to all of the cache keys?

[rhenium]

Oh, I had misunderstood how it works. We could encode the current week or month into the cache key, although I suspect this is still good enough for our purposes.

[junaruga]

Oh, I had misunderstood how it works. We could encode the current week or month into the cache key, although I suspect this is still good enough for our purposes.

The "this" means the current master branch including this PR's commit? That means you think it's okay to cache openssl-master and aws-lc-latest permanently as a possibility? Could you explain more about the context?

[rhenium]

ruby/openssl doesn't have commits every week, so I wouldn't expect stale cache to stay for a long time. But yes, including the current week number for -master and -latest builds seems like the proper fix.

[junaruga]

ruby/openssl doesn't have commits every week, so I wouldn't expect stale cache to stay for a long time. But yes, including the current week number for -master and -latest builds seems like the proper fix.

All right. Thanks for explaining the context. Yes, ruby/openssl doesn't have commits every week. I sent the PR #1110 to fix properly as a follow-up.