-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
gh-115383: Use runner version to compute config.cache key #115409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Our GitHub actions build caches the results of "configure" on macOS and Linux. Periodically, GitHub releases new images for their actions runners. This incorporates the runner's OS and image version to compute the config.cache restore key to avoid using a stale configure cache.
06b31ef
to
cb945c2
Compare
Default environment variables like "ImageVersion" are not available through the env context. Unfortunately, ImageVersion is not available in the "github" context either so we manually re-add it to the environment as IMAGE_VERSION.
@hugovk - after a few false starts, I think this is ready for review! The macOS tests passed, but I'm going to manually re-run them to see how they behave on subsequent runs. |
Of the three runs, I looked at the just the macos-14 jobs. Each run has two jobs running in parallel (free-threaded and regular). For the first run, there's no cache, as expected. At the end of the first run, they try and save the cache. One succeeds. The other doesn't, because "another job may be creating this cache". Fair enough. For the second run, I would have expected the cache to be there, but both said it wasn't found, even though they used the same key as the first run. That is odd. At the end of the run, one job saves the cache, and the other tries but can't. For the third run, the same thing happens -- no cache found, then one saves, one doesn't. I wonder what was going on? Not enough time between runs? |
It looks to me like the cache is successfully restored on subsequent runs, but things might be confusing because I only re-ran one macOS runner each time 1. GitHub shows the jobs from attempt 1 in attempt 2 if they were not re-run.
These look the expected behavior to me. All the runners happened to use image "20240204.1", which is either lucky or unlucky depending on how you look at it. Footnotes
|
Oh, I only re-ran the macos-13 jobs because that's where we saw failures. Feel free to re-run some or all jobs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, let's merge and get the CI unblocked! Thanks!
Thanks @colesbury for the PR, and @hugovk for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11, 3.12. |
…onGH-115409) (cherry picked from commit 4deb705) Co-authored-by: Sam Gross <colesbury@gmail.com>
Sorry, @colesbury and @hugovk, I could not cleanly backport this to
|
GH-115427 is a backport of this pull request to the 3.12 branch. |
GH-115428 is a backport of this pull request to the 3.11 branch. |
pythonGH-115409) (cherry picked from commit 4deb705) Co-authored-by: Sam Gross <colesbury@gmail.com>
Our GitHub actions build caches the results of "configure" on macOS and Linux. Periodically, GitHub releases new images for their actions runners. This incorporates the runner's OS and image version to compute the config.cache restore key to avoid using a stale configure cache.