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
When a target relies on a continuous target that is configured with readyWhen, the readyWhen configuration of the continuous target is not honored and the specified target executes immediately, before the continuous target has met the readyWhen conditions.
Use Case: Test suite relies on dev target but must wait for dev to be ready before it starts to execute tests. With dev configured as continuous, there needs to be a way to ensure that tests don't start until dev is fully ready. The only way that it appears nx supports this configuration is via readyWhen but readyWhen is ignored when continuous is configured.
Expected Behavior
readyWhen should be honored for continuous targets and targets that depend on the continuous target not started until readyWhen conditions are met.
The doc description for readyWhen is somewhat contradictory to the name of the option so possibly I am misunderstanding the intent/purpose of this option. The docs use the terminology done, but the name of the option is readyWhen so it's not 100% clear if this is supposed to indicate when a task is "done" or "ready". Given the name, the assumption is that when it's "ready" which would align with the use case described above as it relates to continuous tasks.
Running npx nx run waitForDevReadyWhen waits for devReadyWhen as expected since devReadyWhen is not configured as continuous
Workaround is to have a separate non-continuous target waitForDev that dependsOn the continuous target dev and "polls" (e.g. checks a /health route for 200) and have the test target dependsOn waitForDev instead of dev. While this works as needed, it's all unnecessary configuration and readyWhen should be honored regardless of continuous configuration value (or another stock method to support this incredibly likely common use case added).
Current Behavior
When a target relies on a
continuoustarget that is configured withreadyWhen, thereadyWhenconfiguration of thecontinuoustarget is not honored and the specified target executes immediately, before thecontinuoustarget has met thereadyWhenconditions.Use Case: Test suite relies on
devtarget but must wait fordevto be ready before it starts to execute tests. Withdevconfigured ascontinuous, there needs to be a way to ensure that tests don't start untildevis fully ready. The only way that it appears nx supports this configuration is viareadyWhenbutreadyWhenis ignored whencontinuousis configured.Expected Behavior
readyWhenshould be honored forcontinuoustargets and targets that depend on thecontinuoustarget not started untilreadyWhenconditions are met.GitHub Repo
https://github.com/techfg/nx-21-continuous-tasks-repros
Steps to Reproduce
git clone https://github.com/techfg/nx-21-continuous-tasks-repros.gitnpx nx run waitForDevReadyWhenContinuousActual Behavior:
waitForDevReadyWhenContinuousstarts immediately and does not wait untildevReadyWhenContinuoushas met itsreadyWhenconditionsNx Report
Failure Logs
Package Manager Version
npm 10.9.2
Operating System
Additional Information
done, but the name of the option isreadyWhenso it's not 100% clear if this is supposed to indicate when a task is "done" or "ready". Given the name, the assumption is that when it's "ready" which would align with the use case described above as it relates tocontinuoustasks.npx nx run waitForDevReadyWhenwaits fordevReadyWhenas expected sincedevReadyWhenis not configured ascontinuousnx:run-commandsdoes not honorreadyWhenwhen only one command configured #31495non-continuoustargetwaitForDevthat dependsOn thecontinuoustargetdevand "polls" (e.g. checks a /health route for 200) and have the test target dependsOnwaitForDevinstead ofdev. While this works as needed, it's all unnecessary configuration andreadyWhenshould be honored regardless ofcontinuousconfiguration value (or another stock method to support this incredibly likely common use case added).