You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have some automation that puts together multiple bundles with different sets of packages. Lately this has gotten to be quite slow. It appears that this is because git information isn't always cached.
I created a test manifest that fully pins each package to a specific commit, but there looks to be a missed opportunity to use cached package information:
There were a few simple optimizations that could be made to speed up the git bits.
I also found that if you attempt to bundle a local git repo, it ends up being cloned twice, once just to get a list of the tags. Since it's already a local repo, that clone can be skipped.
Cool! it's not a totally full fix, but changing the process of building bundles to cloning all repositories across the manifests, then rewriting the manifests to use the local clones results in being able to build all the bundles in 2 minutes vs 20.
Just the branch I have gets things down from 9s to 6s or so. The "clone first then bundle local repos" takes 2.75s.
We have some automation that puts together multiple bundles with different sets of packages. Lately this has gotten to be quite slow. It appears that this is because git information isn't always cached.
I created a test manifest that fully pins each package to a specific commit, but there looks to be a missed opportunity to use cached package information:
here's how I am testing:
then I run
Each run the output looks like
I figure this can't work if you used = master as the version, but pinning a specific version should be able to be cached, right?
The text was updated successfully, but these errors were encountered: