feat(turborepo): --continue=dependencies-successful #10023
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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`
|
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. |
jenseng
commented
Feb 21, 2025
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! 😅
jenseng
commented
Feb 21, 2025
chris-olszewski
requested changes
Feb 21, 2025
anthonyshew
reviewed
Feb 24, 2025
Co-authored-by: Anthony Shew <anthonyshew@gmail.com>
jenseng
added a commit
to jenseng/turborepo
that referenced
this pull request
Feb 25, 2025
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)
chris-olszewski
pushed a commit
that referenced
this pull request
Feb 25, 2025
### Description Fix minor oversight in #10023 when we reworded the options ### Testing Instructions N/A
chris-olszewski
pushed a commit
that referenced
this pull request
Feb 27, 2025
### 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 🥳
chris-olszewski
added a commit
that referenced
this pull request
Mar 5, 2025
) ### Description #10023 added values for the `--continue` flag, but this unintentionally broke commands such as `turbo --continue build` as `build` would be interpreted as a `continue` value ### Testing Instructions Added failing test for the previous breakage and updated snapshots.
|
[UPD] Ah, I see it should be fixed with #10097! Thanks! Hello, @jenseng. Thanks for this update. We started to get the error using The error we are getting is npx turbo run --continue test --filter="@prod-ops/delivery-list" --filter="@prod-ops/vertical-gantt" in /Users/vladkampov/netflix/prod-ops-ui
ERROR invalid value 'test' for '--continue [<CONTINUE>]'
[possible values: never, dependencies-successful, always]
For more information, try '--help'.
node:internal/errors:984
const err = new Error(message);
^
Error: Command failed: npx turbo run --continue test --filter="@prod-ops/delivery-list" --filter="@prod-ops/vertical-gantt"It seems that with the change in 2.4.4, turbo is strict about the order of the flags used. It simply may be worked around if we change the order (like in the PR), however, you might want to work around it differently or document this quirk. Thanks. |
|
@vladkampov sorry about that, that was an unfortunate oversight on my part! v2.4.5 will have a fix for this, but in the meantime there are a few things you can do:
|
No worries! |
1 task
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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