We now have two working jobs on releases-jenkins:
- mediawiki-core-pipeline-wmf-publish which builds a single-version image from a given wmf branch of mediawiki/core
- mediawiki-config-pipeline-wmf-publish which builds a multi-version image from operations/mediawiki-config master branch, copying from single-version image for each version in wikiversions.json and applies security patches (soon, private settings as well)
These jobs need to be automated/scheduled to some degree. I propose:
1. MediaWiki single-version builds happen for every merge to wmf/* branches
The mediawiki-core-pipeline-wmf-publish job is triggered by change-merged gerrit events using the Gerrit Trigger Plugin for all wmf/* branches of core/extension/skin repos. An image containing all MediaWiki code for the branch is built and published as docker-registry.wikimedia.org/wikimedia/mediawiki:{branch}.
The number of events/builds per branch should be relatively low, anywhere between 1-15 per train cycle. The releases-jenkins instance would need to have the plugin installed and be configured with an account that has ssh and Stream Events access.
2. Production (multi-version + config) builds are triggered for every newly published wmf/ image, config change, or security patch change
The mediawiki-config-pipeline-wmf-publish job polls the rsync modules on the deployment host for security patches and private settings changes, change-merged Gerrit events on mediawiki-config, and the registry for newly published wmf/* branch images.