-
Notifications
You must be signed in to change notification settings - Fork 288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
engine: trigger mode auto without inital #4292
Conversation
After this change, is there still a strong reason to group "AutoInit" and TriggerMode together into one identifier? now that they're orthogonal, it doesn't seem like this makes sense anymore. |
Particularly worried about this given that in the new world (with @milas 's FileWatch stuff), "TriggerModeAuto" is just a FileWatch object, and has nothing to do with auto-init...though I haven't totally thought through how auto_init is represented in the new data model. |
Off the top of my head no, no reason to keep them lumped together like this--you're right that it makes more sense to store them as two separate things. (@landism could speak more to why we grouped them together in the backend in the first place?) Is this a "consideration for the future" or do you think figuring out the next step of the data model should block this PR? To me, this change feels like an immediate benefit that doesn't make it any harder for us to refactor things in future, but I'm willing to be wrong. |
how hard would it be to split them into separate fields in this PR? as you pointed out in your original comment, it seems like the PR is already going through some contortions / weird names to keep them together... |
Like, pretty easy but not trivial if I want to get all the testing right |
internal/engine/buildcontroller.go
Outdated
@@ -211,7 +211,7 @@ func buildStateSet(ctx context.Context, manifest model.Manifest, specs []model.T | |||
|
|||
isLiveUpdateEligibleTrigger := reason.HasTrigger() && | |||
reason.Has(model.BuildReasonFlagChangedFiles) && | |||
manifest.TriggerMode != model.TriggerModeAuto | |||
manifest.TriggerMode != model.TriggerModeAuto_AutoInit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this needs to include all TriggerMode=auto?
internal/store/engine_state.go
Outdated
@@ -681,7 +681,7 @@ func (ms *ManifestState) UpdateStatus(triggerMode model.TriggerMode) model.Updat | |||
hasPendingBuild := false | |||
if ms.TriggerReason != 0 { | |||
hasPendingBuild = true | |||
} else if triggerMode == model.TriggerModeAuto && hasPendingChanges { | |||
} else if triggerMode == model.TriggerModeAuto_AutoInit && hasPendingChanges { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this needs to include all auto?
pkg/model/trigger_mode.go
Outdated
@@ -11,26 +11,29 @@ type TriggerMode int | |||
// for an update | |||
const ( | |||
// Tilt automatically performs initial and non-initial builds without manual intervention | |||
TriggerModeAuto TriggerMode = iota | |||
TriggerModeAuto_AutoInit TriggerMode = iota |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i thought Golang names didn't have underscores, cf https://golang.org/doc/effective_go#mixed-caps
maybe call them
TriggerOnManualOnly
TriggerOnFileChange
TriggerOnInit
TriggerOnFileChangeOrInit
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean they're not supposed to have underscores, no, that's why I said i was cheating 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm...were you going to change the names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh whoops i missed this. fixing now.
high-level question that came up when I was talking to another team about this: My understanding is that we want to mark tests as trigger-mode=manual and auto-init=false. How does this play out in CI mode? Seems like you'd want ci mode to run the tests in that case |
How do you figure? I would assume trigger-mode=auto, and auto-init honestly depends on a given user's preference so I would just leave it as the default (which is =true).
I mean, depends what you're using CI mode for--if you just want to make sure your k8s configs are correct and your services stand up right, you don't (necessarily) care about test results. I'd err on the side of not changing default behaviors -- if people need to, they can set |
all that said, if you're worried, we don't have to merge this. I think it'll make the experience of tests a lot nicer, but we can also wait to hear that from more users, or take longer to plan this out. |
nah, if this makes the test experience much nicer, let's move forward with it. i think you're misunderstanding my above comment - in the current PR, if you have a test with trigger-mode=auto and auto-init=false, and you run |
Ah, thought this was a high-level behavior comment. Fixed. |
pkg/model/trigger_mode.go
Outdated
@@ -11,26 +11,29 @@ type TriggerMode int | |||
// for an update | |||
const ( | |||
// Tilt automatically performs initial and non-initial builds without manual intervention | |||
TriggerModeAuto TriggerMode = iota | |||
TriggerModeAuto_AutoInit TriggerMode = iota |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm...were you going to change the names?
rename trigger modes to not use underscores
Previously, you could not have a resource that had `auto_init=False` with `trigger_mode=TRIGGER_MODE_AUTO`. This restriction was lifted in v0.19.1 a while back by tilt-dev/tilt#4292. This removes mention of the restriction from the docs including retconning a blog post from 2019.
Previously, you could not have a resource that had `auto_init=False` with `trigger_mode=TRIGGER_MODE_AUTO`. This restriction was lifted in v0.19.1 a while back by tilt-dev/tilt#4292. This removes mention of the restriction from the docs including retconning a blog post from 2019.
Previously, you could not have a resource that had `auto_init=False` with `trigger_mode=TRIGGER_MODE_AUTO`. This restriction was lifted in v0.19.1 a while back by tilt-dev/tilt#4292. This removes mention of the restriction from the docs including retconning a blog post from 2019.
Allow
TRIGGER_MODE_AUTO
withauto_init=False
, i.e. resources that update automatically in response to changes in watched files, but do NOT automatically update when you first start Tilt.I was dogfooding tests and trying the approach of "one resource per test file/test suite" and getting super frustrated waiting for them all to run at once--here's a solution where only the test resources I need will run (...assuming I get dependency logic right).
I know i'm kind of cheating with the golang constant names, suggestions welcome.
Also not positive what i should do with the trigger mode toggle logic in the FE, but this seems like an ok first guess?