feat(actions): parallel actions

[daniellacosse]

<- blocked by https://github.com/Jigsaw-Code/outline-client/pull/1291

---

npm run action \
  "cordova/build android" \
   "cordova/build osx" \
    -- --parallel

gives:

https://user-images.githubusercontent.com/3759828/167172444-d0f59d15-7eb5-46be-ba89-52e554379ccb.mov

[bemasc]

I don't understand the motivation for this. Why not just run the commands in parallel using shell features, or in separate shells? But really, why run them in parallel at all?

Also, this feels we're incrementally inventing a new build system, which doesn't seem like a good idea. We should be trying to delete code from our build system, not add it.

[daniellacosse]

I don't understand the motivation for this. Why not just run the commands in parallel using shell features, or in separate shells? But really, why run them in parallel at all?

Also, this feels we're incrementally inventing a new build system, which doesn't seem like a good idea. We should be trying to delete code from our build system, not add it.

1. Why not just run the commands in parallel using shell features - can't use shell commands in Windows (w/o cygwin, anyway)
2. Why run them in parallel at all - saving time on internal release
3. We're incrementally inventing a new build system - The alternative is a monorepo, which breaks forkers, and is much much much more work. With this PR it's basically done, sans any future maintenance of the 200-line runAction file.

[jyyi1]

Add my two cents here. I feel the performance improvement is not a big deal for now. The mixed output is also hard to debug. I think @bemasc's idea of using shells to run multiple commands at the same time should work if you want to build the code in parallel. (just create multiple shell windows or tabs, and type in the commands)

[daniellacosse]

Add my two cents here. I feel the performance improvement is not a big deal for now. The mixed output is also hard to debug. I think @bemasc's idea of using shells to run multiple commands at the same time should work if you want to build the code in parallel. (just create multiple shell windows or tabs, and type in the commands)

I'm going to leave this open for now - I suspect there will still be a use case for this down the line, if not builds, maybe scripting multiple linters and test suites to run simultaneously, for instance.

In the case of using multiple tabs, I suspect it will take long enough to set up each time (making sure you have the right ENV variables in each tab since we can't store them or use an .env) that it won't really be worth the hassle. Would rather just run a serial script and go get a cup of coffee.

I hear you on interleaved output, but every monorepo task runner I know of handles this basically the same way. And in fact, I think the way I've done it here is actually somewhat better - I was playing around with yarn workspaces this last weekend and it was completely unclear what log belonged where. Lerna.js actually does prepend each log with its source command but that project is in maintainence mode now (edit: ah, they're being handed to another dev).

If you need to really debug, you can simply re-run that broken command again on its own - nothing's forcing you to run stuff in parallel with this. Or pipe it into grep.

[daniellacosse]

I'll second @jyyi1's comment. The build performance is not really a significant issue for now, and I believe it will make it harder to understand what's going on and find issues.

There will be a bunch of race conditions. I can't even imagine what Cordova will do pulling platforms and plugins in parallel. Also, many common-dependencies (e.g. www) are actually platform-specific and can't really be shared. The different targets will be competing.

I feel like you didn't read what I wrote:

I'm going to leave this open for now - I suspect there will still be a use case for this down the line, if not builds, -> maybe scripting multiple linters and test suites to run simultaneously, for instance. <-

I also wanted to follow up on this specific point, after thinking about it some more. We don't even pass the platform into the www build. What evidence do you have to suggest it's platform-specific?

[daniellacosse]

Closing in favor of a monorepo approach.