tl;dr: publishing REST modules to the REST Sandbox currently requires a config change/deploy. Make publishing the default for audience designations that allow it. Adjust overrides to maintain existing production behavior.
Details
Publishing a MW REST API module to the REST Sandbox currently requires adding an entry to the RestSandboxSpecs config variable. However, the most common case is that module authors want their module published. Change the system so that enabled modules are automatically published. Special-case modules that should not be published can prevent this via the RestModuleOverrides config variable.
The set of published modules is determined in the ModuleManager::getApiSpecDefs() function. Right now, this function combines the hard-coded set of specs in ModuleManager::CORE_SPECS with the specs listed in RestSandboxSpecs.
Change ModuleManager::getApiSpecDefs() to include all enabled modules, unless their audience designation or RestModuleOverrides indicates they should not be published.
The mapping of functionality sets to audience designations can also be changed:
- public => published
- beta => published
This is possible at this time because the config change mentioned below will prevent any undesired publishing. Also, beta will eventually become "opt-in", but we won't yet have the ability to visually distinguish modules in the REST Sandbox. For now, "published" will maintain existing production behavior.
Notes
We have at least one special case, and maybe two:
- the site.v1 module should not be published in the REST Sandbox. This is not expected to change.
- the attribution.v0-beta module should only be published to the REST Sandbox on testwiki. This may change if T422771: REST: Audience Designations - publish modules to REST Sandbox by default is implemented first. In that case, attribution.v0-beta is no longer a special case and can be published everywhere.
Before merging the core change that will be created as part of this task, create and deploy a change to RestModuleOverrides marking both of these as "discoverable".
Checklist
- create/deploy config change to prevent the special case(s) from being published in undesired places
- change ModuleManager::getApiSpecDefs() behavior per the task description
- change the designation/functionality set mapping per the task description