You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a depends on b and turbo.json has specifies ^build for test task dependencies, and I run turbo run test --filter=a, turbo should build b then test a. turbo should not run test on b.
Describe the solution you'd like
Split the notion of package entrypoints from the graph of packages to be considered when resolving task dependencies. Currently, packages that are not selected are removed from the dependency graph before resolving task dependencies. This means that either b won't be built, or the task (test) will also be applied to b if --include-dependencies is specified.
I would like to instead apply the task to all of the selected entrypoints, and then use the full package-dependency graph to resolve pipeline dependencies.
Describe alternatives you've considered
Passing --include-dependencies usually works, but it is not a guarantee. Further, it will almost certainly do extra work, and in the worst case (e.g. watch tasks) may be incompatible.
The text was updated successfully, but these errors were encountered:
)
Fixes#912
In this PR:
* Stop removing unreferenced packages from the package dependency graph before building the task graph.
* Remove the implied `--include-dependencies` if `--scope` and `--since` are both set. It should no longer be necessary.
* Remove the test for `--scope` and `--since` implying `--include-dependencies`
* Add a new scheduler test that mimics the way `run` now behaves.
* Add a debugging profile for doing a dry run against the kitchen sink example.
Future work includes being able to write a test in `run_test.go` to get the whole end-to-end graph build, but we don't quite have the infrastructure for that yet (also required for follow-on work to #911)
Note that this is technically a breaking change. Previously, if `a` depends on `b`, and the `"test"` task depends on `"^build"` the following would be true:
* `turbo run test --scope=a` would test `a` but not build `b`
* `turbo run test --scope=a --include-dependencies` would build `b` and test `a` *AND* `b`.
With this change, `turbo run test --scope=a` will now build `b` and test `a`. The addition of tasks running for unselected packages is new. While this seems like more work being done, in practice I expect users to be able to move from the second example above to the first, ultimately resulting in less work being done: `b#test` will no longer need to run to get `a#test` to run.
Describe the feature you'd like to request
If
a
depends onb
andturbo.json
has specifies^build
for test task dependencies, and I runturbo run test --filter=a
, turbo should buildb
then testa
. turbo should not run test onb
.Describe the solution you'd like
Split the notion of package entrypoints from the graph of packages to be considered when resolving task dependencies. Currently, packages that are not selected are removed from the dependency graph before resolving task dependencies. This means that either
b
won't be built, or the task (test
) will also be applied tob
if--include-dependencies
is specified.I would like to instead apply the task to all of the selected entrypoints, and then use the full package-dependency graph to resolve pipeline dependencies.
Describe alternatives you've considered
Passing
--include-dependencies
usually works, but it is not a guarantee. Further, it will almost certainly do extra work, and in the worst case (e.g.watch
tasks) may be incompatible.The text was updated successfully, but these errors were encountered: