gate-and-submit-swat is for immediate-to-prod code. Yes, mw-config is in its own queue, but it should also have priority…

FWIW, gate-and-submit and gate-and-submit-swat have the same priority.

Zuul is currently limited by gearman WRT priorities; there's only low, normal, and high and these are set per pipeline. Both of these pipelines are have high priority: https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/02e7020ff51b29fbeaf491d32aeb523fe221c90f/zuul/layout.yaml#515

Moving it over to gate-and-submit-swat shouldn't affect its scheduling AFAIU; however, this isn't the first time this has been requested.

TLDR: we do not need to move operations/mediawiki-config to gate-and-submit-swat.

The repository configuration:

- name: operations/mediawiki-config
  gate-and-submit:
    - operations-mw-config-hhvm-composer-test-docker
    - operations-mw-config-php70-composer-lint-docker
    - operations-mw-config-php72-composer-lint-docker
    - operations-mw-config-typos-docker

The jobs are not used on any other repositories, thus operations/mediawiki-config is its in own sub queue in the gate-and-submit (which already has high precedence). Changes +2ed are thus in the high priority queue just like for gate-and-submit and are not delayed by changes coming from other repositories which might be enqueued ahead of it.

gate-and-submit-swat processes Code-Review +2 events solely for the branches wmf/.*:

name: gate-and-submit-swat
trigger:
  gerrit:
    - event: comment-added
      branch: wmf/\d\.\d{2}\.\d-wmf\.\d{1,2}

Thus if we moved operations/mediawiki-config got gate-and-submit-swat, its change would NOT be processed since they are targeting the master branch.

@Addshore tried previously ( d1e23e549e13f15d7a14a8feaf3439766cf4c920 ) and as noted in his commit message:

This will not work because of the current branch matching of wmf/\d\.\d{2}\.\d-wmf\.\d{1,2}

:-]

In T225252#5241899, @thcipriani wrote:

FWIW, gate-and-submit and gate-and-submit-swat have the same priority.

Zuul is currently limited by gearman WRT priorities; there's only low, normal, and high and these are set per pipeline. Both of these pipelines are have high priority: [..]

Thanks, I didn't know this :) Indeed, it already has its own queue-within-pipeline. Which means it wasn't "behind" any unrelated changes. CI was just busy in general which a separate pipeline wouldn't have changed.