Skip to content

CI: Cache compiled AWS-LC by resolving the latest stable version - #1108

Closed
junaruga wants to merge 1 commit into
ruby:masterfrom
junaruga:wip/ci-cache-aws-lc
Closed

CI: Cache compiled AWS-LC by resolving the latest stable version#1108
junaruga wants to merge 1 commit into
ruby:masterfrom
junaruga:wip/ci-cache-aws-lc

Conversation

@junaruga

@junaruga junaruga commented Sep 7, 2026

Copy link
Copy Markdown
Member

When I was checking ruby/openssl's CI AWS-LC case related to the ruby/rubygems PR ruby/rubygems#9853 (comment) to support AWS-LC in ruby/rubygems, I noticed that we can cache the compiled AWS-LC in ruby/openssl's CI. So, this PR caches the compiled AWS-LC. The steps.resolve-aws-lc.outputs.version is such as aws-lc-5.8.0 which aligns with the current pattern such as openssl-4.0.1 and libressl-4.3.2.

I tested in my fork repository. The steps.resolve-aws-lc.outputs.version is aws-lc-5.8.0, which is the same with the actual latest version released at https://github.com/aws/aws-lc/releases. And I confirmed the aws-lc-5.8.0 was used as part of the cache key, and also was used for git clone -b $AWS_LC_RELEASE. The log is below.

https://github.com/junaruga/ruby-openssl/actions/runs/34117715124/job/101728312189#step:4:4

Run actions/cache@v6
  with:
    path: ~/openssl
    key: openssl-Linux-aws-lc-5.8.0-default
    enableCrossOsArchive: false
    fail-on-cache-miss: false
    lookup-only: false
    save-always: false
Cache not found for input keys: openssl-Linux-aws-lc-5.8.0-default
+ case aws-lc-latest in
++ echo aws-lc-5.8.0
++ sed -e s/aws-lc-/v/
+ AWS_LC_RELEASE=v5.8.0
+ git clone -b v5.8.0 --depth 1 https://github.com/aws/aws-lc.git .
Cloning into '.'...
Note: switching to 'a3d1e685552f05a9ad04a2946962c03e97bdecac'.

Commit message

CI: Cache compiled AWS-LC by resolving the latest stable version

Resolve the AWS-LC latest stable version tag before the cache step using git ls-remote, enabling the cache to use a version-specific key (e.g., aws-lc-5.8.0).

Run git clone with the resolved AWS-LC stable version.

Assisted-by: Claude:Opus 4.6

Resolve the AWS-LC latest stable version tag before the cache step
using `git ls-remote`, enabling the cache to use a version-specific key
(e.g., aws-lc-5.8.0).

Run `git clone` with the resolved AWS-LC stable version.

Assisted-by: Claude:Opus 4.6
@rhenium

rhenium commented Sep 7, 2026

Copy link
Copy Markdown
Member

I don't really want to have to think about AWS-LC's tag naming rules.

Should we just stop disabling the cache for AWS-LC and OpenSSL master builds? CI may use an outdated version for up to a week old (IIRC), but I think that may be acceptable.

@junaruga

junaruga commented Sep 7, 2026

Copy link
Copy Markdown
Member Author

Should we just stop disabling the cache for AWS-LC and OpenSSL master builds? CI may use an outdated version for up to a week old (IIRC), but I think that may be acceptable.

You remember the cache enabled term correctly. I found the following text in actions/cache repository.

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.

OK. Let me try on the way "stop disabling the cache for AWS-LC and OpenSSL master builds". As the implementation is quite different from this PR, I will open a new PR closing this PR.

@junaruga

junaruga commented Sep 7, 2026

Copy link
Copy Markdown
Member Author

OK. Let me try on the way "stop disabling the cache for AWS-LC and OpenSSL master builds". As the implementation is quite different from this PR, I will open a new PR closing this PR.

I sent the PR #1109.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants