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: 0850022

Run: 33166067267

	Env	💚​RECOVERED	🙈​SKIP	✅​pass	🙈​skip	Time
💚​	aws linux	1	1	274	1210	4:12
💚​	aws windows	1	1	276	1208	4:25
💚​	azure linux	1	1	273	1210	4:24
💚​	azure windows	1	1	275	1208	4:34
💚​	gcp linux	1	1	274	1210	5:00
💚​	gcp windows	1	1	276	1208	4:14

	Test Name	aws linux	aws windows	azure linux	azure windows	gcp linux	gcp windows
💚​	TestAccept	💚​R	💚​R	💚​R	💚​R	💚​R	💚​R
🙈​	TestAccept/ssh/connection	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S

Top 3 slowest tests (at least 2 minutes):

duration	env	testname
4:28	azure windows	TestAccept
4:21	aws windows	TestAccept
4:09	gcp windows	TestAccept

[github-actions]

Approval status: pending

/acceptance/bundle/ - needs approval

44 files changed
Suggested: @denik
Also eligible: @janniklasrose, @pietern, @andrewnester, @shreyas-goenka, @lennartkats-db, @anton-107

/bundle/ - needs approval

20 files changed
Suggested: @denik
Also eligible: @janniklasrose, @pietern, @andrewnester, @shreyas-goenka, @lennartkats-db, @anton-107

/cmd/bundle/ - needs approval

Files: cmd/bundle/utils/process.go
Suggested: @denik
Also eligible: @janniklasrose, @pietern, @andrewnester, @shreyas-goenka, @lennartkats-db, @anton-107

General files (require maintainer)

Files: .nextchanges/bundles/job-runs-on-file-change.md
Based on git history:

• @denik -- recent work in bundle/direct/, bundle/phases/, bundle/deployplan/

_{Any maintainer (@andrewnester, @anton-107, @denik, @pietern, @shreyas-goenka, @simonfaltum, @renaudhartert-db, @janniklasrose, @lennartkats-db, @rugpanov, @rclarey) can approve all areas.
See OWNERS for ownership rules.}