In T172480#11373318, @Krinkle wrote:

I assume Scap still has the concept of applying the next image to a canary pool in mw-on-k8s first, waiting some time for a potential Logstash error rate increase, and then deciding whether to proceed.

Unless a canary pool was introduced for mw-jobrunner since then, this is presumably still limited to the mw-web and mw-api server groups, and thus still an issue.

There was. This can be discerned very easily via a search in the deployment-charts repo and is visible in https://github.com/wikimedia/operations-deployment-charts/blob/master/helmfile.d/services/mw-jobrunner/helmfile.yaml#L20

Note the canary release mentioned in lines 20 and 24 (for eqiad and codfw respectively).

The glue with scap is defined in https://github.com/wikimedia/operations-puppet/blob/production/hieradata/role/common/deployment_server/kubernetes.yaml#L207

Where the profile::kubernetes::deployment_server::mediawiki::release::mw_releases stanza defines kinds, flavours and stages. At line 251 there is the stanza for mw-jobrunner and names the canary release, which is being upgrades during the scap canaries stage. This is also how any future release in any service that gets deployed by scap could get used during the canaries stage of scap.

Given the above, I am gonna be bold and resolve this, I think the needs of the task have been resolved for at least 1 year now (probably more, but I 'll avoid going down the successive git blame rabbit hole).