fix!: only add target_tasks_method filter if no other filters were sp…

…ecified

BREAKING CHANGE: The target_tasks_method is now only implicitly added if
no other filters exist.

This is needed to fix a bug in Gecko's `./mach try` infrastructure,
however the change makes sense on its own. Currently there's no way to
forego target_tasks_method, and this allows us to do that.

Furthermore, there are no other built-in filters, so it's unlikely that
this will impact any existing consumers.

docs/reference/migrations.rst

@@ -3,6 +3,26 @@ Migration Guide
 
 This page can help when migrating Taskgraph across major versions.
 
+11.x -> 12.x
+------------
+
+* Add ``target_tasks_method`` to the front of the filters parameter wherever
+  you are also using a custom filter.
+
+  For example, if you are passing in:
+
+  .. code-block:: yaml
+
+     filters: ["my_custom_filter"]
+
+  Change it to:
+
+  .. code-block:: yaml
+
+     filters: ["target_tasks_method", "my_custom_filter"]
+
+  No action is necessary if the ``filters`` parameter was empty.
+
 10.x -> 11.x
 ------------
 

src/taskgraph/generator.py

@@ -269,9 +269,9 @@ def _run(self):
         logger.debug(f"Dumping parameters:\n{repr(parameters)}")
 
         filters = parameters.get("filters", [])
-        # Always add legacy target tasks method until we deprecate that API.
-        if "target_tasks_method" not in filters:
-            filters.insert(0, "target_tasks_method")
+        if not filters:
+            # Default to target_tasks_method if none specified.
+            filters.append("target_tasks_method")
         filters = [filter_tasks.filter_task_functions[f] for f in filters]
 
         yield self.verify("parameters", parameters)