CI: DMR chair actions no longer trigger a publish and site deploy

Pressing Run DMR batch or Check for unmerged batches starts a pipeline on main, which fired the whole thing.

Pipeline 5649 is representative — dmr-reconcile did its work in 15 seconds and pulled five minutes of tests, scanners, publish, packaging and a Pages deploy of the live site along behind it.

Why they are redundant, not just expensive

Neither DMR job changes main. Reconcile only relabels GitLab issues over the API; a batch writes its rows to a dmr/batch-* branch. So publish, package-*, build-website and pages run against a tree byte-identical to the last publish — rebuilding the same artefacts and redeploying an unchanged site. The real publish happens when the batch MR is merged, which fires its own pipeline on main.

Redeploying a live UN service as a side effect of tidying issue labels is risk with no corresponding benefit.

Change

A shared .skip-on-dmr-trigger anchor sits first in the rules for normalize-csv-quoting, test-python, test-java, publish, package-release, package-skos, build-website and pages:

if: '$TRIGGER_DMR_BATCH == "true" || $DMR_RECONCILE == "true"'
when: never

A normal push to main leaves those variables unset, the rule evaluates false, and every existing rule applies unchanged — verified in both directions.

Left alone

The three gemnasium-* scanners come from the included Dependency-Scanning template. Overriding a template's rules means replicating defaults that are not visible here, and they are cheap and side-effect free. They also keep the pipeline non-empty, which GitLab requires.

dmr-batch still appears on a reconcile pipeline, but it is a manual button and will not run on its own.