Allow concurrency to be set with percentage values

[VanTanev]

Closes #761

This is modeled after the way that jest allows to set workers by providing a percent with --maxWorkers=50%.

I've updated Turbo's CLI parsing to accept --concurrency=50%. It also supports percentages over 100%, so --concurrency=500% is valid. It uses runtime.NumCPU() to get the number of available logical processors, and calculates from there.

Setting the percentage to zero or less is an error. Setting percentage very low, to eg 1% results in always at least 1 as the value for concurrency.

[vercel]

@VanTanev is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[VanTanev]

I would also want to work on adding the concurrency setting to the turbo.json config file but wanted to submit one PR at a time.

[VanTanev]

@jaredpalmer Is there anything I can do to help move this PR forward? Any changes I should do?

[gsoltis]

Overall this looks solid. Just one minor nit.

[gsoltis]

Minor nit, but I think the Go convention is to return the zero-value for a type when also returning an error. Here and elsewhere in this function.

[VanTanev]

Fixed, thanks!

[VanTanev]

I want to also write a PR to allow default concurrency to be set in turbo.json - are you open to the idea, and do you have any specific requirements around that?

[gsoltis]

@VanTanev Maybe start a discussion for the config file? turbo.json is intended to be checked in and shared, and it's not immediately clear to me that everyone would want to default to the same concurrency. Just as an example, I would imagine your CI might want 100% while devs might prefer some headroom left over. My intuition is that this is a setting that is per-machine, like login information. But happy to get input from the community on what would be helpful here.

[moltar]

@VanTanev Thanks for this PR!

IMO having an environment config would be more useful than having an entry in the config file.

To me, turbo.json config is something permanent, that is project-dependant, and does not change from environment to environment.

But what changes from environment to environment are ... the environment variables 😁

I might want to run at 100% on CI, and at 50% on my local machine, because it's busy doing other things.

And that's what the environment variables are exactly for! I could even configure my local env permanently via bashrc to always run turbo on 50% settings (again, because I want to use my dev box while it's running builds, regardless of the project). But I always want to take up 100% of the CI.

And if turbo is just another command in a custom build script, then I lose control of the concurrency setting via CLI option and I also cannot change the config from env to env.

[VanTanev]

@moltar Can I add both, with precedence going argument > env > turbo.json?

[moltar]

Can I add both

@VanTanev I am not the project maintainer, merely the one who raised issue #761 😁

But I personally see no value in having it inside the config. But to each their own!