feat(turborepo): --continue=dependencies-successful #10023
Conversation
Convert `--continue` into a tri-state option, introducing a new mode that allows independent tasks to continue running when an error occurs (dependent tasks will be canceled). The possible values for `--continue` are now: - `none` (default) -- on error: cancel all tasks - `independent-tasks-only` -- on error: cancel dependents, but continue others - `all` -- on error: always continue, including dependents For backwards compatibility, `false` (i.e. `none`) and `true` (i.e. `all`) are still accepted, but will emit a deprecation warning. Setting `--continue` without a value is equivalent to setting it to `all`
turbo-orchestrator
bot
added
area: docs
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
@jenseng is attempting to deploy a commit to the Vercel Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
A couple high level thoughts on the UX:
- Do we want to deprecate the ability to specify
--continuewithout a value? --continue=independent-tasks-onlyis a bit verbose IMO. What if we did something like--continue=independent?- Or we could deprecate
--continueentirely and have a new option that inverts the phrasing, e.g. something like--on-errorwith values likehalt,cancel-dependentsandcontinue
Also I'm a rust noob, so please let me know where I can improve! 😅
|
The windows tests have been failing consistently in this PR and I haven't seen that failure on other PRs/pushes. I did a debug run here where I undid this change to setup_integration_tests.sh, and that seems to have fixed it 🙃 ... not sure how that would break things, maybe hitting a weird bug/edge case in Git for Windows' bash.exe? 🤷 ... doing a couple more test runs to confirm, and if that theory holds i'll revert that line |
Yeah looking quite likely to be the culprit, since the new PATH value is inappropriate for bash.exe and likely causing trouble. i.e. it's setting something like: I'll revert that line from this PR and revisit it in another PR (I think it's a good change to make, just needs to work on windows) |
Head branch was pushed to by a user without write access
Co-authored-by: Anthony Shew <anthonyshew@gmail.com>
extracted from vercel#10023 fix an issue running integration tests locally (depends on how you have corepack installed) setup_package_manager.sh exports PATH, so we need to source it for that to actually take effect. with PATH now set, we also need to make sure it's valid under bash.exe (windows GHA runners)
### Description Fix minor oversight in #10023 when we reworded the options ### Testing Instructions N/A
### Description Spun out from #10023 (comment) setup_package_manager.sh exports `PATH`, so we need to source it for the isolated corepack shims to actually get used in tests. Otherwise certain npm integration tests can fail, depending on the global npm version and if corepack's npm shims haven't been explicitly enabled globally. This can lead to false positives and wasted time debugging integration tests locally. This hasn't been an issue under GitHub Actions, since actions/setup-node is installing the same version of npm (10.5.0) that the tests expect, but could otherwise become problematic down the road. Fixing this uncovers two new problems around testing under Windows, which this PR also addresses: - the corepack path needs to be POSIX-ified, since `C:\Users\RUNNER~1\...` contains backslashes and the name separator (:) - corepack uses `PATHEXT` (via [cmd-extension](https://www.npmjs.com/package/cmd-extension)) to determine the casing of its shims' file extension (e.g. npm.cmd vs npm.CMD), whereas node's bundled npm.cmd is always lowercase ... while we could update all the tests to accept both styles, the easiest thing to do is just to downcase `PATHEXT`. ### Testing Instructions Integration tests 🥳
Description
Context: #7461
Convert
--continueinto a tri-state option, introducing a new mode that allows independent tasks to continue running when an error occurs (dependent tasks will be canceled).The possible values for
--continueare now:never(default) -- on error: cancel all tasksdependencies-successful-- on error: continue running tasks whose dependencies have succeededalways-- on error: continue running all tasks, even those whose dependencies have failedSetting
--continuewithout a value is equivalent to setting it toalwaysTesting Instructions
See modified/added tests in the PR, but basically:
turbo run <cmd> --continue=never(or omitting it) will abort when an error occursturbo run <cmd> --continue=dependencies-successfulwill cancel dependent tasks when an error occurs, but keep running othersturbo run <cmd> --continue=always(or--continue) will keep running all other tasks when an error occurs