Skip to content

Add change-detection to a gate

Most gate components (lint, test, build, docs — not security; see Security, always-on) ship a changes array input, already default-on with a conservative glob list. Most of the time you don't need to touch it — but three situations do call for extending, narrowing, or disabling it. Read Explanation: change-detection first if you want the reasoning; this page is just the recipe.

Extend it: your project has a path the default doesn't cover

The most common case. A Go project embedding a Svelte UI is the canonical example — go-test's default changes watches Go source and module files, but not the frontend directory whose build the embedded tests assert on. Override the input with the default plus your extra path(s):

include:
  - component: gitlab.com/phpboyscout/cicd/[email protected]
    inputs:
      changes:
        - "**/*.go"
        - "**/go.mod"
        - "**/go.sum"
        - ".golangci.*"
        - ".gitlab-ci.yml"
        - "pkg/studio/web/**"   # the addition

There's no "extend" syntax — overriding changes replaces the default entirely, so copy the component's documented default from its Reference page and add your path(s) to it. Check the Svelte frontend track explanation page if this is exactly your situation — it documents the go-test extension as a requirement, not just an option, for embed projects.

Narrow it: your repo layout doesn't match the default's assumptions

A monorepo where a component's default working directory doesn't match your layout is the usual trigger — zensical-pages's default changes assumes docs live at the repo root (working_directory: "."); a monorepo with docs under apps/docs/ should narrow the filter to that subtree so an unrelated app's change doesn't trigger a docs rebuild:

include:
  - component: gitlab.com/phpboyscout/cicd/[email protected]
    inputs:
      working_directory: "apps/docs"
      changes:
        - "apps/docs/**/*"
        - ".gitlab-ci.yml"

Keep .gitlab-ci.yml in every override — a CI edit should always re-run the job it configures, regardless of what else you narrow.

Disable it: you want the job to run on every MR, unconditionally

Set the filter to match everything:

inputs:
  changes: ["**/*"]

This is the universal escape hatch on every component that has a changes input — useful while you're not yet confident in a narrower filter, or for a project where the churn savings don't matter enough to accept any false-negative risk.

The one thing not to do: narrow past your own tool config

Whatever you set, keep your project's own tool config in the filter — a .golangci.yml, a deny.toml, a rustfmt.toml. A gate that skips itself when its own configuration changes is a much more confusing bug to diagnose than a slightly-too-broad filter.

See also