no bug - Fix a rst mistake, causing the note to be displayed r=marco DONTBUILD
authorSylvestre Ledru <>
Thu, 14 May 2020 11:05:45 +0000
changeset 593600 dea9d3f363d6e6513997f5aa17e3131beaf8c847
parent 593599 7c0d5a5a3f2a466981091cbe4f8acb50a9617be0
child 593601 9ca31d0721fb91ef7345e024c68f387c481a83c3
push id13186
push userffxbld-merge
push dateMon, 01 Jun 2020 09:52:46 +0000
treeherdermozilla-beta@3e7c70a1e4a1 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
no bug - Fix a rst mistake, causing the note to be displayed r=marco DONTBUILD Depends on D75260 Differential Revision:
--- a/taskcluster/docs/actions.rst
+++ b/taskcluster/docs/actions.rst
@@ -26,17 +26,17 @@ Defining Action Tasks
 There is one options for defining actions: creating a callback action.
 A callback action automatically defines an action task that will invoke a
 Python function of your devising.
 Creating a Callback Action
-.. note:
+.. note::
     You can generate ``actions.json`` on the command line with ``./mach taskgraph actions``.
 A *callback action* is an action that calls back into in-tree logic. That is,
 you register the action with name, title, description, context, input schema and a
 python callback. When the action is triggered in a user interface,
 input matching the schema is collected, passed to a new task which then calls
 your python callback, enabling it to do pretty much anything it wants to.
--- a/taskcluster/docs/optimization-schedules.rst
+++ b/taskcluster/docs/optimization-schedules.rst
@@ -38,17 +38,17 @@ Lint tasks and well separated unittest t
 A good way to keep this straight is to think of exclusive platform-family components (``macosx``, ``android``, ``windows``, ``linux``) and inclusive linting components (``py-lint``, ``js-lint``).
 An arbitrary file in the repository affects all platform families, but does not necessarily require a lint run.
 But we can configure mac-only files such as ```` to affect exclusively ``macosx``, and Python files like ```` to affect ``py-lint`` in addition to the exclusive components.
 It is also possible to define a file as affecting an inclusive component and nothing else.
 For example, the source code and configuration for the Python linting tasks does not affect any tasks other than linting.
-.. note:
+.. note::
     Most unit test suite tasks are allocated to components for their platform family and for the test suite.
     This indicates that if a platform family is affected (for example, ``android``) then the builds for that platform should execute as well as the full test suite.
     If only a single suite is affected (for example, by a change to a reftest source file), then the reftests should execute for all platforms.
     However, some test suites, for which the set of contributing files are well-defined, are represented as inclusive components.
     These components will not be executed by default for any platform families, but only when one or more of the contributing files are changed.
--- a/taskcluster/docs/optimization.rst
+++ b/taskcluster/docs/optimization.rst
@@ -30,17 +30,17 @@ Optimizing Target Tasks
 In some cases, such as try pushes, tasks in the target task set have been
 explicitly requested and are thus excluded from optimization. In other cases,
 the target task set is almost the entire task graph, so targeted tasks are
 considered for optimization. This behavior is controlled with the
 ``optimize_target_tasks`` parameter.
-.. note:
+.. note::
     Because it is a mix of "what the push author wanted" and "what should run
     when necessary", try pushes with the old option syntax (``-b do -p all``,
     etc.) *do* optimize target tasks.  This can cause unexpected results when
     requested jobs are optimized away.  If those jobs were actually necessary,
     then a try push with ``try_task_config.json`` is the solution.
 More Information
--- a/toolkit/components/normandy/docs/execution-model.rst
+++ b/toolkit/components/normandy/docs/execution-model.rst
@@ -47,17 +47,17 @@ a list of capabilities that it supports.
 by the recipe are not compatible with the client, then the recipe does not
 Capabilities are used to avoid running recipes on a client that are so
 incompatible as to be harmful. For example, some changes to filter expression
 handling cannot be detected by filter expressions, and so older clients that
 receive filters using these new features would break.
-.. note:
+.. note::
     Capabilities were first introduced in Firefox 70. Clients prior to this
     do not check capabilities, and run all recipes provided. To accommodate
     this, the server splits recipes into two Remote Settings collections,
     ``normandy-recipes``, and ``normandy-recipes-capabilities``. Clients
     prior to Firefox 70 use the former, whereas Firefox 70 and above use the
     latter. Recipes that only require "baseline" capabilities are published
     to both, and those that require advanced capabilities are only published
--- a/toolkit/components/telemetry/docs/data/backgroundhangmonitor-ping.rst
+++ b/toolkit/components/telemetry/docs/data/backgroundhangmonitor-ping.rst
@@ -39,17 +39,17 @@ Structure:
             "pseudoStack": [ ... ], // List of label stack frames and js frames.
             "stack": [ ... ], // interleaved hang stack, see below.
-.. note: :
+.. note::
   Hangs are collected whenever the current runnable takes over 128ms.
 Process Types
 The ``process`` field is a string denoting the kind of process that hung. Hangs
 are currently sent only for the processes below: