job_runs: add lifecycle.triggers.on_file_change

[radakam]

Changes

Add lifecycle.triggers.on_file_change for resources.job_runs (direct engine).

resources:
  job_runs:
    migrate:
      job_id: ${resources.jobs.migrate.id}
      lifecycle:
        triggers:
          - on_file_change: migrations/*.sql

• Resolve the path or glob relative to the defining YAML file and require the result to stay under the sync root.
• Fingerprint after build (for bundle plan / bundle validate) and after predeploy (for bundle deploy). Hash through the same SyncRoot VFS used by sync, so WSFS notebooks and generated overlays are included. An mtime-only touch does not re-fire.
• Match against the files sync would upload (libs/sync.FileList + path.Match), including sync's generated include patterns. .gitignore and sync.exclude are honored. Directories never appear in that list, so migrations/* hashes only regular files.
• Persist internal lifecycle.triggers_state as normalized-pattern → aggregate-hash entries, plus a UUID for on_bundle_deploy. Each aggregate hashes the sorted matched paths and their content hashes. Unarmed runs omit lifecycle from state. A no-match pattern stores the empty-set hash under the same pattern key used once files appear.
• Re-fire when an aggregate hash changes or when matches appear or disappear. Removing a trigger leaves the existing run alone and writes a state-only update that clears the fingerprint (no Jobs API call). Re-adding the trigger therefore arms and fires it again without requiring an intervening file edit. A removed file still recreates the run.
• Reject absolute patterns, patterns outside the sync root, empty patterns, ** (path.Match treats it as two ordinary stars, not recursive), and combining a trigger with prevent_destroy. Warn when no synced files match; the empty-set fingerprint still re-arms once a matching file appears. Pattern errors are reported at validate time; hashing runs only when planning or deploying.

Why

Users need to re-run a job when local inputs change (SQL migrations, notebooks, configs) without re-firing on every deploy. Content hashes keep the trigger stable under sync noise while still catching real edits.

Fingerprints must be computed after build and predeploy scripts, otherwise a trigger on a generated file fires one deploy late. Hashing through SyncRoot keeps notebook and overlay content consistent with what sync uploads.

A pattern that hashes nothing used to look like an unarmed trigger. Recording an empty-set fingerprint under a stable pattern key makes those cases re-arm later, so they are warnings rather than deploy failures.

Fingerprints live on triggers_state, not on the YAML triggers list, so user config and planner state stay distinct. Clearing a trigger must persist that omission; otherwise re-adding it looks unchanged and never fires.

Tests

• Unit: aggregate content hashing, SyncRoot overlay reads, absolute-pattern rejection, and sync-root-relative missing-pattern keys; trigger validation for empty and invalid entries and prevent_destroy conflicts; state-only classification when a trigger is removed; omission of empty lifecycle from serialized state.
• Acceptance:
  • on_file_change — first deploy fires; unchanged redeploy and touch plan nothing; an edit recreates (including READPLAN); deleting and restoring the file each re-fire; removing the trigger performs no run-now, clears its state through both live and serialized plans, and re-adding it re-fires.
  • on_file_change_build — a prebuild script rewriting a watched file re-fires the run in that same deploy.
  • on_file_change_glob — migrations/* plus mysubdir/*.txt; matches appearing and disappearing re-fire; files below the glob and gitignored files do not; ** is rejected; READPLAN.
  • on_file_change_errors — pattern outside the sync root (error); directory-only, directory plus sync-excluded, only sync-excluded, and no-match cases (warnings); unsupported ** and an absolute pattern (errors).
  • on_file_change_include_sync_root — patterns from included YAML resolve next to the include, at the bundle root (../), and at the sync root (../../); each edit recreates only the corresponding pattern entry.

[eng-dev-ecosystem-bot]

Integration test report

Commit: f964f6f

Run: 34575944054

	Env	💚​RECOVERED	✅​pass	🙈​skip	Time
💚​	aws linux	1	275	23	4:38
💚​	aws windows	1	277	21	5:05
💚​	azure linux	1	274	23	4:06
💚​	azure windows	1	276	21	5:01
💚​	gcp linux	1	275	23	4:09
💚​	gcp windows	1	277	21	5:00

	Test Name	aws linux	aws windows	azure linux	azure windows	gcp linux	gcp windows
💚​	TestAccept	💚​R	💚​R	💚​R	💚​R	💚​R	💚​R

Top 3 slowest tests (at least 2 minutes):

duration	env	testname
5:02	aws windows	TestAccept
4:58	azure windows	TestAccept
4:58	gcp windows	TestAccept

[janniklasrose]

Suggested change

	* direct: resources.job\_runs: new lifecycle.triggers.on\_file\_change setting to restart the run when monitored files change. Can be set to a series of paths or globs. ([#6309](https://github.com/databricks/cli/pull/6309))
	* direct: `resources.job_runs`: new `lifecycle.triggers.on_file_change` setting to restart the run when monitored files change. Can be set to a series of paths or globs. ([#6309](https://github.com/databricks/cli/pull/6309))

[janniklasrose]

also test D:?