Skip to content
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

[feature] Populate download_cache on upload #13840

Open
1 task done
Ext3h opened this issue May 8, 2023 · 2 comments
Open
1 task done

[feature] Populate download_cache on upload #13840

Ext3h opened this issue May 8, 2023 · 2 comments
Assignees
Milestone

Comments

@Ext3h
Copy link

Ext3h commented May 8, 2023

What is your suggestion?

While core.download:download_cache is a great way to speed up the download step in CI workflows, it unfortunately only serves to speed up the download of common dependencies.

In more complex chains where you have several (dependent) jobs on a common CI infrastructure, it's likely that the package a previous job has just created and uploaded to a remote, will also be directly consumed by a dependent job. In this case, any freshly created artifact will always go the full round-trip of upload and download, even with a cache configured.

Ideally, the compressed package would be forked straight into the download_cache (when configured), so that a following download of the new package is reduced to a noop.

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded
Copy link
Member

Hi @Ext3h

Thanks for your suggestion.
My first thought is that this would be actually more challenging than expected, as the download (with cache) and upload flows and internal architecture are quite decoupled, and this would require coupling them, and also further messing with the download cache (and cache are always challenging).

But it also seems this could make sense, so putting this for consideration into the 2.X roadmap (not a short term thing, because there will be other priorities (functional) and this optimization while good to have is not a blocker). Thanks for the feedback!

@AbrilRBS
Copy link
Member

Work has started for this in #15223

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

No branches or pull requests

3 participants