Add preliminary job_runs resource#5603
Open
radakam wants to merge 23 commits into
Open
Conversation
Collaborator
Integration test reportCommit: 9129a5b
21 interesting tests: 13 SKIP, 7 KNOWN, 1 RECOVERED
Top 4 slowest tests (at least 2 minutes):
|
radakam
force-pushed
the
job-runs-resource
branch
from
63df005 to
ff9faea
Compare
radakam
force-pushed
the
job-runs-resource
branch
from
a899c09 to
3fb23a7
Compare
Contributor
Approval status: pending
|
radakam
force-pushed
the
job-runs-resource
branch
from
d6b00f5 to
f7ec335
Compare
radakam
force-pushed
the
job-runs-resource
branch
from
9df3417 to
8a71c9e
Compare
These pypi-proxy registry rewrites in python/uv.lock and python/codegen/uv.lock were environment artifacts unrelated to the job_runs resource. Restore both lockfiles to match main.
A run's URL needs both its run id and its parent job id. The run id is
restored from state like any resource, but the job id in config comes from
a ${resources.jobs.*.id} reference that is only resolved at deploy, so at
read time it is 0 and the URL would render as jobs/0/runs/<runid>.
Restore the run's resolved job_id from state at load time (same mechanism
as id and the dashboard etag), then build the URL in JobRun.InitializeURL.
denik
reviewed
Jun 24, 2026
A job run is immutable and fire-once, so it should re-trigger only when its own RunNow config changes, never from edits to the targeted job or from out-of-band remote drift. Remove the job_settings snapshot field (whose sole purpose was to make job edits re-trigger the run), drop it from DoRead and the resources.yml lifecycle rules, and ignore remote changes for every run input so only a local change recreates the run. Regenerate schema, validation, and refschema artifacts, and remove the notebook_change acceptance test whose premise (job edit re-triggers run) no longer applies.
Add a job_run config to the invariant suite so the no_drift check (deploy -> plan shows 0 drift -> destroy) covers job_runs, guarding that a triggered run shows no perpetual drift on redeploy. Exclude it from the migrate (direct-only, no terraform converter) and continue_293 (resource absent in v0.293.0) invariants, mirroring vector_search/genie_space.
# Conflicts: # acceptance/bundle/invariant/continue_293/out.test.toml # acceptance/bundle/invariant/migrate/out.test.toml # acceptance/bundle/invariant/no_drift/out.test.toml # acceptance/bundle/invariant/test.toml
Return (false, nil) on a 404 from GetRun via apierr.IsMissing, matching the newer resources, so only real lookup failures propagate as errors. Add a NEXT_CHANGELOG.md entry for the job_runs resource.
Replace PLACEHOLDER annotations for the top-level job_runs resource and its lifecycle field with real descriptions, and regenerate jsonschema.json.
…rigger scope Add a `bundle plan` between the config edit and redeploy in the job_runs redeploy acceptance test so the golden output explicitly shows the `recreate job_runs.my_run` action, making the "config change re-triggers the run" behavior visible at the plan level. Reword the DoRead and resources.yml comments to frame "re-trigger only on the run's own config change" as the current milestone scope, with re-triggering on other signals (every deploy, file/value changes) noted as later-milestone work.
denik
reviewed
Jun 25, 2026
| # list below. DoRead records only the run's identity (job_id), which it | ||
| # confirms but does not re-trigger on. | ||
| ignore_remote_changes: | ||
| - field: dbt_commands |
Contributor
There was a problem hiding this comment.
question - not sure if it works; if we include literal empty string as field, will it cover all fields?
| // only resolved at deploy; restoring the deployed value lets read-only | ||
| // commands build the run URL. | ||
| var jobID int64 | ||
| if strings.Contains(key, ".job_runs.") && len(entry.State) > 0 { |
Contributor
There was a problem hiding this comment.
can this trigger for resources.jobs.job_runs.permissions?
I know this follows pattern from the above, but maybe we should fix that as well.
| if err != nil { | ||
| return nil, err | ||
| } | ||
| run, err := r.client.Jobs.GetRun(ctx, jobs.GetRunRequest{ |
Contributor
There was a problem hiding this comment.
If we don't use the result of GetRun, do we still need to call it? If run cannot be deleted (according to comment in DoDelete), then presence of id means it was created, we can trust it.
Contributor
There was a problem hiding this comment.
i do see there is https://docs.databricks.com/api/workspace/jobs/deleterun
should not we try to delete it?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
New
job_runsbundle resource.Triggers one run of an existing job during
bundle deploy— the bundle equivalent ofjobs run-now. The run appears inbundle summarywith a clickable URL.Re-trigger only on the run's own config change.
A run is immutable, so there's no update path. It re-triggers (no-op delete + fresh
RunNow) only when its own inputs change (e.g.job_parameters,job_id); editing the targeted job or out-of-band changes don't re-trigger it. Implemented viarecreate_on_changes+ignore_remote_changes;DoReadrecords only the run's identity, and a missing run (404) is treated as not-found viaapierr.IsMissing.Why
Today, triggering a job as part of bundle deploy requires custom scripts outside the bundle. This project (this is the first milestone) adds a
resources.job_runssection to DABs (direct engine) so users can declaratively run jobs as part of deployment. e.g., schema migrations, model training, data prep.Tests
DATABRICKS_BUNDLE_ENGINE=direct):basic,redeploy,job_parameters.no_driftinvariant extended to coverjob_runs; excluded frommigrateandcontinue_293.bundle/direct/dresources/...,bundle/config/resources/...,libs/structs/structwalk/....