jackbentley
commented
2 years ago I might be wrong, but I think this is probably either:
- an optimisation problem in the built JS code
- JS initialization problem
- or, slow retrieval from the env
There's not that much happening before the JS code exits on the "Cache hit occured" check.
https://github.com/actions/cache/blob/6bbe742add91b3db4abf110e742a967ec789958f/src/save.ts#L14
This is the first thing to happen when it enters the post-run code. This builds a new URL and checks the hostname - which seems rather non-intensive.
Code Snippet
https://github.com/actions/cache/blob/6bbe742add91b3db4abf110e742a967ec789958f/src/utils/actionUtils.ts#L5-L10https://github.com/actions/cache/blob/6bbe742add91b3db4abf110e742a967ec789958f/src/save.ts#L21
The next it just checks for the existence of a key in the process env. Again, non-intensive.
Code Snippet
https://github.com/actions/cache/blob/6bbe742add91b3db4abf110e742a967ec789958f/src/utils/actionUtils.ts#L50-L54https://github.com/actions/cache/blob/6bbe742add91b3db4abf110e742a967ec789958f/src/save.ts#L30-L34
Next, we again just pull more info from the env (be it through a couple of function calls) then do basic statement checks.
Code Snippet
https://github.com/actions/cache/blob/6bbe742add91b3db4abf110e742a967ec789958f/src/utils/actionUtils.ts#L35-L43 ```js // from https://github.com/actions/toolkit/blob/e2eeb0a784f4067a75f0c6cd2cc9703f3cbc7744/packages/core/src/core.ts#L355-L357 export function getState(name: string): string { return process.env[`STATE_${name}`] || '' } ```https://github.com/actions/cache/blob/6bbe742add91b3db4abf110e742a967ec789958f/src/save.ts#L39
Finally, we get to the comparison before the exit. Which is simply just a comparison of the params using a JS internal method.
malcolmstill
github-actions[bot]
Jack-Works
eduardomoroni
aparna-ravindra
kotewar
smorimoto
I'm trying to optimize our build time by cache TypeScript build cache and Webpack build cache. Things work well,
TypeScript build time 1m35 => 16s, Webpack build 5m52s => 2m22s
But the total time does not short for too much, I found out the problem is the post-job cleanup of this action.
All primary keys hits and no new cache updated but it spent 2m17s~ to complete the job. I think that is very strange.
If it is the case, I expect it will complete in 5 seconds.
Here is our config:
The problematic action: https://github.com/DimensionDev/Maskbook/pull/3279/checks?check_run_id=2715205805