job_runs: add lifecycle.triggers.on_bundle_deploy - #6231
Merged
Conversation
Collaborator
Integration test reportCommit: 8811a06
8 interesting tests: 4 SKIP, 3 RECOVERED, 1 flaky
Top 8 slowest tests (at least 2 minutes):
|
radakam
marked this pull request as ready for review
August 11, 2026 14:23
denik
reviewed
Aug 17, 2026
| // JobRunTriggersState is the persisted fingerprint of lifecycle.triggers. | ||
| type JobRunTriggersState struct { | ||
| // Fresh UUID each plan when on_bundle_deploy is set so Old!=New forces recreate. | ||
| OnBundleDeploy string `json:"on_bundle_deploy,omitempty"` |
Contributor
There was a problem hiding this comment.
q: Do we need UUID? Would storing last serial be enough?
Contributor
Author
There was a problem hiding this comment.
Serial would be nicer for deterministic plans and more readable state, but UUID keeps the fingerprint self-contained in PrepareState. That avoids plumbing deployment state through the resource interface for a value that's just compared for inequality. I'd keep UUID, but I'm happy to switch if deterministic plans are the priority:)
Contributor
There was a problem hiding this comment.
Since it's implementation detail, we can change it later, so we can land like this.
Maybe there is general framework feature missing that will make it easier (like making last deployed serial available to all resources).
Let users re-fire a run on every deploy via a trigger fingerprint in state, so unchanged config still plans recreate. File/value modes are parsed but rejected until follow-up PRs.
Ship only on_bundle_deploy for now; add the other modes when implemented.
Say what the trigger does instead of what it does not.
Trigger fingerprint removal can recreate once; keep the same model for future triggers.
Every-deploy recreate cannot succeed when destroy is forbidden.
Include idempotency_token in on_bundle_deploy output and regenerate refschema fields for JobRunLifecycle triggers.
Catch invalid on_bundle_deploy configs at bundle validate, not only plan/deploy.
…er lifecycle Removing lifecycle.triggers.on_bundle_deploy left a UUID fingerprint in state that the next plan compared against nil, so the run was recreated one last time after the user had already opted out. OverrideChangeDesc now skips the change when the fingerprint is cleared, at whichever path structdiff reports it. The fingerprint also moves from a top-level "triggers" field to lifecycle.triggers, mirroring the config shape and leaving room for a future Jobs API field of the same name.
Match the per-resource deploy/destroy output from #5720 after merging main.
radakam
force-pushed
the
deco-job-runs-lifecycle-on-bundle-deploy
branch
from
August 17, 2026 13:31
b1eb64e to
1d3830a
Compare
denik
reviewed
Aug 18, 2026
| // JobRunTriggersState is the persisted fingerprint of lifecycle.triggers. | ||
| type JobRunTriggersState struct { | ||
| // Fresh UUID each plan when on_bundle_deploy is set so Old!=New forces recreate. | ||
| OnBundleDeploy string `json:"on_bundle_deploy,omitempty"` |
Contributor
There was a problem hiding this comment.
Since it's implementation detail, we can change it later, so we can land like this.
Maybe there is general framework feature missing that will make it easier (like making last deployed serial available to all resources).
Add a READPLAN variant so the fingerprint minted at plan time is exercised through plan serialization: a --plan deploy persists that fingerprint and still recreates the run, and a cleared fingerprint still plans no drift. Also hoist the direct-engine matrix and RecordRequests into parent test.toml files, since every job_runs test repeated them. Removing a test.toml drops one file from the synced bundle, hence the upload counts in three goldens.
Nothing reads the job_runs lifecycle through the interface: the only caller of GetLifecycle type-asserts to LifecycleWithStarted, and prevent_destroy is read from the dyn config in checkForPreventDestroy. Add it back together with the first generic consumer, such as lifecycle.depends_on.
Leaving the UUID in state via Skip works for on_bundle_deploy but would orphan meaningful hashes for later triggers; Update drops the fingerprint without re-firing the run.
denik
approved these changes
Aug 19, 2026
Lock in the recreate vs state-only-update distinction from the serialized plan, not only the human-readable summary.
Collaborator
Integration test reportCommit: dc733eb
13 interesting tests: 5 flaky, 3 RECOVERED, 2 KNOWN, 2 SKIP, 1 FAIL
Top 50 slowest tests (at least 2 minutes):
|
Collaborator
Integration test reportCommit: dc733eb
391 interesting tests: 346 MISS, 37 FAIL, 5 RECOVERED, 2 KNOWN, 1 SKIP
Top 50 slowest tests (at least 2 minutes):
|
denik
reviewed
Aug 24, 2026
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
3 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
Adds
lifecycle.triggers.on_bundle_deploy: truefor experimentaljob_runs(direct engine): re-fire the run on every bundle deploy.JobRunLifecycle.triggersshadowsBaseResource.Lifecycle.PrepareStatestores a fresh UUID fingerprint under statelifecycle.triggers.on_bundle_deployso the existing recreate rule fires every deploy.Update(OverrideChangeDesc+DoUpdateno-op on lifecycle paths) so the fingerprint is dropped from state without re-firing the run.on_bundle_deploymust betruewhen set; incompatible withlifecycle.prevent_destroy.Without the trigger, behavior is unchanged.
Why
Users need a declarative "run this every deploy" switch (migrations, seed jobs) without editing run config to force a recreate.
Tests
knownMissingInRemoteTypefor local-onlylifecyclestaterun-now; removing the trigger plans a state-only update with norun-now. Runs underREADPLAN=["", "1"]so a--plandeploy also persists the fingerprint and still recreatesRecordRequestshoisted to parenttest.tomls (upload-count shifts in three goldens are from dropping those files from the synced bundle)