-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
Add request caching to Dockerfile generator #536
Conversation
When developing parts of the Dockerfile generation pipeline, and thus regenerating Dockerfiles over and over, many unnecessary HTTP requests are being made to https://api.adoptium.net, since the data is mostly unchanged. Adding a request cache with an expiration time of an hour allows this regeneration to run in under a second in most case, while not compromising on the correctness.
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.
This will exacerbate the timing window already present in this logic, as the retrieval of the assets at the centre of the configuration/version/image_type loop is requested as the 'ga' which may change during the script run if you were unfortunate to be running while a Temurin release is underway - though I accept that is unlikely. The failure would be a skewed set of release images.
On the basis that this is run for production usage only beyond a Temurin release I'm happy to approve.
We could implement a parameter to skip cache? Then maybe say that for workflow_dispatch runs (e.g manual ones) it skips it? WDYT? |
Hmm. I thought that workspace is cleaned before a build and thus the cache file is gone (i's in |
hmm yes this is a good point, this only affects local development. In which case I'm happy |
Yes, I'm happy to leave as is based on the original post that ... This would not affect the usual usage. I did momentarily consider whether it should have a guard only set for local development, but that seem unnecessary. Deploying for production and in GHA it is a single run through and we wouldn't be making repeated calls to the same API anyway. |
When developing parts of the Dockerfile generation pipeline, and thus regenerating Dockerfiles over and over, many unnecessary HTTP requests are being made to https://api.adoptium.net, since the data is mostly unchanged. Adding a request cache with an expiration time of an hour allows this regeneration to run in under a second in most case, while not compromising on the correctness.