potiuk commented on PR #43394: URL: https://github.com/apache/airflow/pull/43394#issuecomment-2439730222
> Very cool! Will this save a few seconds in CI as well? Should - in a number of cases - depending on whether cache was used or not. But in some it won't. The actual answer to that is pretty complex and I still am not sure if I know all the cases. For locally installing pre-commits for the first time (or after you run `pre-commit clean`, it should definitely speed up installation - as it will use uv to install all the venvs. In CI we already used cache, so it would save some more time when deps are changing for "canary" builds - where generally cache is reused from past builds. Here the saving is not that obvious - uv has its own cache and we are not storing it separately as uv cache is generally quite huge and storing it in cache / restoring it in gh actions would add an overhead, and in most cases "installed packages" serve as cache as well. Generally it should speed up situation where cache is not used, but savings should be less where cash is stored - unless we haevily change dependencies that will invalidate most of the venvs in the cache. But the way cache is used in PRs from fork is somewhat complex when PRs from forks and multiple branches are involved. See https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache - I am not 100% sure how it works in all cases, but in general for sure cache is shared between multiple runs of the same PR (i.e. when you rebase) - but cache is not shared from main to a fork-PR. But cache is shared with a PR from apache repo AFAIK. Did I mention that caching is hard? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
