feat: build/pack in parallel #914
Conversation
| @@ -13,6 +13,7 @@ This can be used to create oclif CLIs that use the system node or that come prel | |||
| root: Flags.string({char: 'r', description: 'path to oclif CLI root', default: '.', required: true}), | |||
| targets: Flags.string({char: 't', description: 'comma-separated targets to pack (e.g.: linux-arm,win32-x64)'}), | |||
| xz: Flags.boolean({description: 'also build xz', allowNo: true}), | |||
| parallel: Flags.boolean({description: 'build tarballs in parallel'}), | |||
There was a problem hiding this comment.
Is there a reason not to have parallel as the default? Why would anyone prefer to run them sequentially?
There was a problem hiding this comment.
I only did this to avoid breaking changes in people's scripts [imagine someone using free CI tier with smaller vm/ lower memory]
|
@mshanemc if we merge this into main then it'll be released in v3, which is not being used by sf or sfdx. You can see W-10989572 for more but the gist is that v3 adds support for M1 builds, which would require us to make a handful of changes in our release process. So if you want this feature before we do all that work, we'll need to create a v2 branch and merge that change there. Update: we decided to go ahead and do that while you're out |
add a
--paralleloption to the pack command to speed things along.local packing on
2.4 GHz 8-Core Intel Core ioriginal: 9m58s
--parallel: 3m17s