refactor!: rename 'job' transforms to 'run'

BREAKING CHANGE: `taskgraph.transforms.job` moved to
`taskgraph.transforms.run`

docs/concepts/kind.rst

@@ -30,9 +30,9 @@ look at a simple build kind example, you'll notice at the top the `loader` and
 `transforms` are defined. These point to standard taskgraph, but if you wanted
 to use a custom loader or transform it would be defined here pointing to
 `your_project_name_taskgraph` directory, eg
-`my_project_name_taskgraph.transforms.job`. If no loader is specified,
+`my_project_name_taskgraph.transforms.run`. If no loader is specified,
 `taskgraph.loader.default:loader` will be used, which will bring with it
-`taskgraph.transforms.job` and `taskgraph.transforms.task` as default
+`taskgraph.transforms.run` and `taskgraph.transforms.task` as default
 transforms.
 
 This can also be a clue of where to look if you are trying to understand what a

docs/concepts/loading.rst

@@ -46,7 +46,7 @@ The :mod:`Transform Loader<taskgraph.loader.transform>` is a barebones loader.
 
 The :mod:`Default Loader<taskgraph.loader.default>` does everything that the
 Transform Loader does, and additionally ensures that the
-:mod:`Job<taskgraph.transforms.job>` and :mod:`Task<taskgraph.transforms.task>`
+:mod:`Run <taskgraph.transforms.run>` and :mod:`Task<taskgraph.transforms.task>`
 transforms are used on every task it loads.
 
 Projects may optionally provide their own loaders that support different

docs/concepts/task-graphs.rst

@@ -100,8 +100,8 @@ Transitive closure is a fancy name for this sort of operation:
  * add all tasks on which any of those tasks depend
  * repeat until nothing changes
 
-The effect is this: imagine you start with a linux32 test job and a linux64
-test job. In the first round, each test task depends on the test docker image
+The effect is this: imagine you start with a linux32 test task and a linux64
+test task. In the first round, each test task depends on the test docker image
 task, so add that image task. Each test also depends on a build, so add the
 linux32 and linux64 build tasks.
 
@@ -112,7 +112,7 @@ the set depend on a task not in the set, so nothing changes and the process is
 complete.
 
 And as you can see, the graph we've built now includes everything we wanted
-(the test jobs) plus everything required to do that (docker images, builds).
+(the test tasks) plus everything required to do that (docker images, builds).
 
 Dependencies
 ------------

docs/concepts/transforms.rst

@@ -166,29 +166,29 @@ stages defined by schemas. The process begins with the raw data structures
 parsed from the YAML files in the kind configuration. This data can processed
 by kind-specific transforms resulting in a "kind specific description".
 
-From there, it's common for tasks to use the :mod:`job transforms
-<taskgraph.transforms.job>` which provide convenient utilities for things such
+From there, it's common for tasks to use the :mod:`run transforms
+<taskgraph.transforms.run>` which provide convenient utilities for things such
 as cloning repositories, downloading artifacts, caching and much more! After
-these transforms tasks will conform to the "job description".
+these transforms tasks will conform to the "run description".
 
 Finally almost all kinds should use the :mod:`task transforms
 <taskgraph.transforms.task>`. These transforms massage the task into the
 `Taskcluster task schema`_
 
-Job Descriptions
+Run Descriptions
 ................
 
-A job description defines what to run in the task. It is a combination of a
+A *run description* defines what to run in the task. It is a combination of a
 ``run`` section and all of the fields from a task description. The run section
 has a ``using`` property that defines how this task should be run; for example,
 ``run-task`` to run arbitrary commands, or ``toolchain-script`` to invoke a
 well defined script. The remainder of the run section is specific to the
 run-using implementation.
 
-The effect of a job description is to say "run this thing on this worker". The
-job description must contain enough information about the worker to identify
+The effect of a run description is to say "run this thing on this worker". The
+run description must contain enough information about the worker to identify
 the workerType and the implementation (docker-worker, generic-worker, etc.).
-Alternatively, job descriptions can specify the ``platforms`` field in
+Alternatively, run descriptions can specify the ``platforms`` field in
 conjunction with the ``by-platform`` key to specify multiple workerTypes and
 implementations. Any other task-description information is passed along
 verbatim, although it is augmented by the run-using implementation.

docs/howto/create-tasks.rst

@@ -67,7 +67,7 @@ to the ``tasks`` object:
 
    The format of the tasks depends heavily on which :term:`transforms
    <Transform>` the kind uses. In this example, Taskgraph is implicitly adding
-   the :mod:`~taskgraph.transforms.job` and :mod:`~taskgraph.transforms.task`
+   the :mod:`~taskgraph.transforms.run` and :mod:`~taskgraph.transforms.task`
    transforms. See :doc:`/concepts/transforms` for more information.
 
 Task Defaults

docs/howto/use-fetches.rst

@@ -15,7 +15,7 @@ in its payload.
 Using Fetches
 -------------
 
-Fetches are implemented as part of the :mod:`~taskgraph.transforms.job`
+Fetches are implemented as part of the :mod:`~taskgraph.transforms.run`
 transforms. So first make sure your task's ``kind.yml`` file is using those
 transforms:
 
@@ -24,7 +24,7 @@ transforms:
    loader: taskgraph.loader.transform:loader
 
    transforms:
-     - taskgraph.transforms.job:transforms
+     - taskgraph.transforms.run:transforms
 
 
 Now let's say we're creating a test task. We'll need to download and

docs/reference/migrations.rst

@@ -3,6 +3,12 @@ Migration Guide
 
 This page can help when migrating Taskgraph across major versions.
 
+6.x -> 7.x
+----------
+
+* Replace references to `taskgraph.transforms.job` with `taskgraph.transforms.run`.
+* Rename the `run_job_using` decorator to `run_task_using`.
+
 5.x -> 6.x
 ----------
 

docs/reference/source/taskgraph.transforms.rst

@@ -7,7 +7,7 @@ Subpackages
 .. toctree::
    :maxdepth: 4
 
-   taskgraph.transforms.job
+   taskgraph.transforms.run
 
 Submodules
 ----------

docs/reference/source/taskgraph.transforms.job.rst → docs/reference/source/taskgraph.transforms.run.rst

@@ -1,45 +1,45 @@
-taskgraph.transforms.job package
+taskgraph.transforms.run package
 ================================
 
 Submodules
 ----------
 
-taskgraph.transforms.job.common module
+taskgraph.transforms.run.common module
 --------------------------------------
 
-.. automodule:: taskgraph.transforms.job.common
+.. automodule:: taskgraph.transforms.run.common
    :members:
    :undoc-members:
    :show-inheritance:
 
-taskgraph.transforms.job.index\_search module
+taskgraph.transforms.run.index\_search module
 ---------------------------------------------
 
-.. automodule:: taskgraph.transforms.job.index_search
+.. automodule:: taskgraph.transforms.run.index_search
    :members:
    :undoc-members:
    :show-inheritance:
 
-taskgraph.transforms.job.run\_task module
+taskgraph.transforms.run.run\_task module
 -----------------------------------------
 
-.. automodule:: taskgraph.transforms.job.run_task
+.. automodule:: taskgraph.transforms.run.run_task
    :members:
    :undoc-members:
    :show-inheritance:
 
-taskgraph.transforms.job.toolchain module
+taskgraph.transforms.run.toolchain module
 -----------------------------------------
 
-.. automodule:: taskgraph.transforms.job.toolchain
+.. automodule:: taskgraph.transforms.run.toolchain
    :members:
    :undoc-members:
    :show-inheritance:
 
 Module contents
 ---------------
 
-.. automodule:: taskgraph.transforms.job
+.. automodule:: taskgraph.transforms.run
    :members:
    :undoc-members:
    :show-inheritance:

docs/reference/transforms/from_deps.rst

@@ -272,7 +272,7 @@ entry:
              - artifact: target.tar.gz
 
 The above block will add a ``fetches`` entry to the task that is compatible with ``taskgraph`` 's
-:mod:`~taskgraph.transforms.job` transforms.
+:mod:`~taskgraph.transforms.run` transforms.
 
 In some cases, artifact names may be different for different upstream tasks within the same kind.
 You can often handle this by setting an attribute in the upstream tasks, which ``from_deps`` can

docs/tutorials/creating-a-task-graph.rst

@@ -85,7 +85,7 @@ you have a ``hello`` kind. For this next section we'll be editing
 
 #. Declare the set of :term:`transforms <transform>` that will be applied
    to tasks. By default, taskgraph will include the
-   :mod:`-taskgraph.transforms.job` and :mod:`-taskgraph.transforms.tasks`
+   :mod:`-taskgraph.transforms.run` and :mod:`-taskgraph.transforms.task`
    transforms, which are used by the vast majority of simple tasks. It is also
    quite common for kind-specific transforms to be used, which we will do here
    for the purpose of demonstration. In our example:
@@ -99,7 +99,7 @@ you have a ``hello`` kind. For this next section we'll be editing
    initial definition here can vary wildly from one kind to another, it all
    depends on the transforms that are used. It's conventional for transforms to
    define a schema (but not required). So often you can look at the first
-   transform file to see what schema is expected of your job. But since we
+   transform file to see what schema is expected of your task. But since we
    haven't created the first transforms yet, let's define our task like this
    for now:
 

pyproject.toml

@@ -50,7 +50,7 @@ exclude = [  # TODO fix errors in these files
     "src/taskgraph/run-task/robustcheckout.py",
     "src/taskgraph/transforms/fetch.py",
     "src/taskgraph/transforms/task.py",
-    "src/taskgraph/transforms/job/run_task.py",
+    "src/taskgraph/transforms/run/run_task.py",
     "src/taskgraph/util/cached_tasks.py",
     "src/taskgraph/util/decision.py",
     "src/taskgraph/util/python_path.py",

src/taskgraph/create.py

@@ -104,7 +104,7 @@ def submit(task_id, label, task_def):
 
 def create_task(session, task_id, label, task_def):
     # create the task using 'http://taskcluster/queue', which is proxied to the queue service
-    # with credentials appropriate to this job.
+    # with credentials appropriate to this task.
 
     # Resolve timestamps
     now = current_json_time(datetime_format=True)

src/taskgraph/decision.py

@@ -46,21 +46,21 @@
 )
 
 
-def full_task_graph_to_runnable_jobs(full_task_json):
-    runnable_jobs = {}
+def full_task_graph_to_runnable_tasks(full_task_json):
+    runnable_tasks = {}
     for label, node in full_task_json.items():
         if not ("extra" in node["task"] and "treeherder" in node["task"]["extra"]):
             continue
 
         th = node["task"]["extra"]["treeherder"]
-        runnable_jobs[label] = {"symbol": th["symbol"]}
+        runnable_tasks[label] = {"symbol": th["symbol"]}
 
         for i in ("groupName", "groupSymbol", "collection"):
             if i in th:
-                runnable_jobs[label][i] = th[i]
+                runnable_tasks[label][i] = th[i]
         if th.get("machine", {}).get("platform"):
-            runnable_jobs[label]["platform"] = th["machine"]["platform"]
-    return runnable_jobs
+            runnable_tasks[label]["platform"] = th["machine"]["platform"]
+    return runnable_tasks
 
 
 def taskgraph_decision(options, parameters=None):
@@ -104,7 +104,7 @@ def taskgraph_decision(options, parameters=None):
 
     # write out the public/runnable-jobs.json file
     write_artifact(
-        "runnable-jobs.json", full_task_graph_to_runnable_jobs(full_task_json)
+        "runnable-jobs.json", full_task_graph_to_runnable_tasks(full_task_json)
     )
 
     # this is just a test to check whether the from_json() function is working

src/taskgraph/loader/default.py

@@ -11,7 +11,7 @@
 
 
 DEFAULT_TRANSFORMS = [
-    "taskgraph.transforms.job:transforms",
+    "taskgraph.transforms.run:transforms",
     "taskgraph.transforms.task:transforms",
 ]
 
@@ -20,7 +20,7 @@ def loader(kind, path, config, params, loaded_tasks):
     """
     This default loader builds on the `transform` loader by providing sensible
     default transforms that the majority of simple tasks will need.
-    Specifically, `job` and `task` transforms will be appended to the end of the
+    Specifically, `run` and `task` transforms will be appended to the end of the
     list of transforms in the kind being loaded.
     """
     transform_refs = config.setdefault("transforms", [])

src/taskgraph/transforms/base.py

@@ -147,7 +147,7 @@ def __call__(self, config, tasks):
                     kind=config.kind, name=task["name"]
                 )
             elif "label" in task:
-                error = "In job {label!r}:".format(label=task["label"])
+                error = "In task {label!r}:".format(label=task["label"])
             elif "primary-dependency" in task:
                 error = "In {kind} kind task for {dependency!r}:".format(
                     kind=config.kind, dependency=task["primary-dependency"].label

src/taskgraph/transforms/code_review.py

@@ -12,12 +12,12 @@
 
 
 @transforms.add
-def add_dependencies(config, jobs):
-    for job in jobs:
-        job.setdefault("soft-dependencies", [])
-        job["soft-dependencies"] += [
+def add_dependencies(config, tasks):
+    for task in tasks:
+        task.setdefault("soft-dependencies", [])
+        task["soft-dependencies"] += [
             dep_task.label
             for dep_task in config.kind_dependencies_tasks.values()
             if dep_task.attributes.get("code-review") is True
         ]
-        yield job
+        yield task