Assignment Rules (beta)

Assignment rules allow you to control which tasks can run on which agents. Save on agent costs by provisioning different sizes of agents all with the confidence that your tasks will be run on the agents that are best suited for them. You can ensure resource intensive targets like e2e-ci and build have what they need by using larger agents. Lighter tasks like lint and test can run on smaller agents.

Assignment rules are defined in yaml files within your workspace's .nx/workflows directory. You can use assignment rules with self-hosted agents or with dynamic Nx agents. Note that the additional configuration is required when using self-hosted agents.

How to Define an Assignment Rule

Each assignment rule has one of the following properties that it matches against tasks: project, target, and/or configuration. It also has a list of possible agent types that tasks with the matching properties can run on. Rules are defined in yaml like the following:

The above rule will match any task that has a project named app1, a target named build, and a configuration named production. Any tasks that match this rule will only be allowed to run on agents with the linux-large-js and linux-medium-js launch templates.

You can mix and match any of the criteria in an assignment rule provided that you follow the constraints:

• At least one of the following properties is defined: project, target, configuration.
• There is at least one agent type specified in the run-on field.
• Every changeset in your distribute-on field must include at least one agent that matches each agent type specified in the run-on field across all assignment rules. For example, if your rules distribute tasks on linux-small-js, linux-medium-js, and linux-large-js, then at least one agent of each type must be available; otherwise, tasks associated with those rules cannot be executed.

Assignment Rule Precedence

Having multiple assignment rules means that often rules may overlap or apply to the same tasks. To determine which rule take priority, a rule of thumb is that more specific rules take precedence over more general rules. You can consult our precedence chart for a full list of rule priorities. A checkmark indicates that a rule has a particular property defined.

Rule Precedence Example

In this example, the task defined below can match multiple assignment rules. However, since the second rule specifies all three properties (project, target, and configuration) rather than just two (project and target), it takes precedence, and we apply the second rule when distributing the task.

Using Assignment Rules with Self-Hosted Agents

A typical assignment-rules.yaml file might look like this:

Note that the labels supplied in the runs-ons property will be used to determine which agents will have rules applied to them. When using self-hosted agents, you must supply these labels to your agents via an environment variable: NX_AGENT_LAUNCH_TEMPLATE.

You can then reference your assignment rules file within your start-ci-run command:

The following is an example of what this looks like within a github actions pipeline:

Using Assignment Rules with Dynamic Nx Agents

A typical distribution-config.yaml file might look like this:

You can then reference your distribution configuration in your CI pipeline configuration:

More Examples of Assignment Rules with Dynamic Agents

Invalid Assignment Rules Example

Valid Assignment Rules Example