The fxms schema job has been updated with a script that writes out the test
corpus for the test. This means we no longer need to keep these JSON files in
tree, since the test will automatically generate them.
Differential Revision: https://phabricator.services.mozilla.com/D151985
The following propertie have been refactored out into the top-level message
schema so that they don't have to be repeated in each template's schema:
- `frequency`
- `groups`
- `id`
- `priority`
A definition for the `trigger` property has been added to the common schemas as
`MessageTrigger` so that messages that require triggering can reference this
definition.
Each template schema now requires only its template (as a const value or enum)
and its content, as well as any additional top-level properties that are
message specific (e.g., `order` for `WhatsNewMessage`).
`id`, `content`, and `template` properties are required for all messages.
Individual template schemas do not need to mark `content` and `template` as
required since they are required by the top-level schema. Messages that
require triggering or targeting must define those properties.
Differential Revision: https://phabricator.services.mozilla.com/D150705
Several kinds of FxMS messages support a common pattern of taking either a
string or an object containing a string ID, allowing for both raw strings and
translated string IDs to be used in messages. This patch refactors that pattern
out into a common definition (localizedText and localizableText) in a common
schema which other schemas can then reference.
Our schema bundling script has been updated to bundle these definitions from
the common schema as top-level definitions (and subsequently rewrite the
references from FxMSCOmmon.schema.json to the generated schema) because Nimbus
and Experimenter only support a single schema file per feature.
To ensure compatability with Experimenter, all our in-tree messages have been
extracted into a test corpus that is validated with the Experimenter JSON
Schema validator. A future patch in this series will clean this up so we don't
need to have separate copies of messages in the tree.
We are now also validating all messages from the CFRMessageProvider with our
in-tree JSON Schema validator that Nimbus uses. The OnboardingMessageProvider
and PanelTestProvider tests have also been updated so that all three are using
the same testing infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D150704
To ensure that we don't ship a schema that breaks Experimenter, we now have
in-tree tests that validate FxMS messages against our schema using the same
JSON Schema evaluator (python-jsonchema).
Our test corpus is the same as test_PanelTestProvider.js. We cannot have
PanelTestProvider.jsm fetch the messages from the JSON due to fetch() not being
supported in the newtab npm tests.
Differential Revision: https://phabricator.services.mozilla.com/D151169
The Nimbus Features corresponding to FxMS messaging surfaces are actually
intended to map to FxMS message groups, which can accept *any* FxMS message.
The features have been updated with schemas that accept any FxMS message.
As part of this, all FxMS schemas have been updated with an `$id` so that they
can be bundled into feature schemas and have their internal `$ref`s work.
(Otherwise, a `$ref` would be relative to the top-level schema instead of the
sub-schema).
Schemas for individual message types are no longer exposed as resource:// URIs,
except in tests, as indivual schemas are no longer required at runtime.
Additionally, each FxMS schema has had its `template` field become required and
requires a constant value for that schema (e.g., Spotlight requires a template
value of "spotlight").
A test has been added to ensure that if any of the messaging surfaces schemas
change that the feature schemas are also updated. The feature schemas can be
regenerated via:
```
cd ./browser/components/newtab/content-src/asrouter/schemas
../../../../../../mach make-schemas.py
```
Differential Revision: https://phabricator.services.mozilla.com/D147332
