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

Added local caching mechanism for list of polkadot-sdk versions to fasten fetch time #28

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

0xsouravm
Copy link
Contributor

This PR introduces a --cache flag to locally store the list of polkadot-sdk versions to exponentially fasten their fetch time compared to the GitHub API or CLI. A --update-cache flag is also added to just update the local cache by freshly fetching the available versions from GitHub.

Key Features:

  1. Cache the versions list to fetch the versions lightning-fast
  2. Update the local cache by freshly fetching versions list from GitHub

Copy link
Member

@ggwpez ggwpez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please not. This tool is very simple. We should keep it simple and only exactly as complicated as necessary.

I dont see any reason to add caching. Projects will use this maybe once per month - most. There is no way we need a cache in this. It this tool was often used, or somehow time critical then i would say yes, but not for this.

This tool has to stay very simple, since it only shows a miss design in how we currently handle releases. It is meant as intermediate solution and nothing that we should try to massively extend. There is no gain from this.

If you want to make a CLI faster, i would suggest https://github.com/paritytech/try-runtime-cli, it runs in CI on every pull request and is currently using CI cached files. It takes about 15 min or more to create a snapshot, but is also difficult to optimize. Anyway, any effort spent here should rather go to a more value bearing project.

@0xsouravm
Copy link
Contributor Author

Please not. This tool is very simple. We should keep it simple and only exactly as complicated as necessary.

I dont see any reason to add caching. Projects will use this maybe once per month - most. There is no way we need a cache in this. It this tool was often used, or somehow time critical then i would say yes, but not for this.

This tool has to stay very simple, since it only shows a miss design in how we currently handle releases. It is meant as intermediate solution and nothing that we should try to massively extend. There is no gain from this.

Oh alright got it. Sorry I thought it would be helpful. Thanks!

@0xsouravm
Copy link
Contributor Author

If you want to make a CLI faster, i would suggest https://github.com/paritytech/try-runtime-cli, it runs in CI on every pull request and is currently using CI cached files. It takes about 15 min or more to create a snapshot, but is also difficult to optimize. Anyway, any effort spent here should rather go to a more value bearing project.

Sure I will give it a look! Thank you so much!

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

Successfully merging this pull request may close these issues.

2 participants