This should be done right away. Assumes feature flag via $wmg or its equivalent.
|Declined||None||T251442 Add PushNotifications extension to release branch cut|
|Resolved||Mholloway||T251437 Create MediaWiki extension for Push Notifications|
|Resolved||Mholloway||T251431 Create .sql for Push Notifications tasks|
|Resolved||MSantos||T251441 CI and test coverage|
|Resolved||• kostajh||T259658 [Bug] SonarQube bot is not working for push-notifications service|
Generally we expect some lose (not necessarily final) security review before putting the code on production servers (even if it's not hooked up, the code will be on disc for all production servers in the next train after this is done).
My understanding of changes related to https://lists.wikimedia.org/pipermail/engineering/2018-March/000520.html is that they intentionally require all code enabled on Beta to be deployed to production, even if in a dormant state. (This appears to have been a unilateral deployment policy change, and I think it was badly misguided and should be reversed.) But to be clear: is it possible to have an extension installed and in a testable state on the Beta Cluster without getting it branched for production? How exactly would one go about setting that up?
No, that was just a simplification of how we listed the extensions for the i18n build; it has been this way since the Beta Cluster was created in 2012.
But to be clear: is it possible to have an extension installed and in a testable state on the Beta Cluster without getting it branched for production? How exactly would one go about setting that up?
Beta Cluster has a copy of extensions.git pinned to master; all 1700 extensions are on disc there and could be loaded in the "normal" way (configuration in CommonSettings.php, InitialiseSettings.php, and for Beta Cluster InitialiseSettings-labs.php).