Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

fix: don't create autostart workspace builds with no available provisioners#19067

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
cstyan merged 18 commits intomainfromcallum-autostart-no-provisioner
Aug 15, 2025

Conversation

cstyan
Copy link
Contributor

This shouldfix#17941

With just the test addition the test will fail since the workspace build is triggered, we attempt to move the workspace into thestart state:require.Equal(t, codersdk.WorkspaceTransitionStop, workspace.LatestBuild.Transition)

    lifecycle_executor_test.go:1718:                 Error Trace:    /home/coder/coder/coderd/autobuild/lifecycle_executor_test.go:1718                Error:          Not equal:                                 expected: "stop"                                actual  : "start"                                                            Diff:                                --- Expected                                +++ Actual                                @@ -1,2 +1,2 @@                                -(codersdk.WorkspaceTransition) (len=4) "stop"                                +(codersdk.WorkspaceTransition) (len=5) "start"                                                 Test:           TestExecutorAutostartSkipsWhenNoProvisionersAvailable

With the 2nd commit we skip the calls towsbuilder.New andbuilder.Build and so the transition is never scheduled.

coder@automatic-builds-test:~/coder/coderd/autobuild$ go test -run TestExecutorAutostartSkipsWhenNoProvisionersAvailablePASSok      github.com/coder/coder/v2/coderd/autobuild      1.134scoder@automatic-builds-test:~/coder/coderd/autobuild$ go test -run TestExecutorAutostartSkipsWhenNoProvisionersAvailable -v | grep autostart    t.go:106: 2025-07-28 22:11:09.405 [warn]  coderd.autobuild: skipping autostart - no available provisioners  workspace_id=219f4901-dfd0-4cdc-8cf2-258861adfd18  workspace_name=dazzling-jemison3-89l

However, many tests don't fully setup provisioner or wait for the provisioner + DB to be fully available, so the third commit adds a somewhat smelly way to skip the provisioner check in tests that don't need to test that functionality.

@cstyancstyan changed the titlefix: don't create autostart workspace builds if there is no available provisioners for the jobfix: don't create autostart workspace builds with no available provisionersJul 29, 2025
@deansheatherdeansheather self-requested a reviewJuly 30, 2025 17:04
provisioner is not availableSigned-off-by: Callum Styan <callumstyan@gmail.com>
transition so that we don't accumulate autostart jobs that willeventually have to be cleaned up by the reaper routineSigned-off-by: Callum Styan <callumstyan@gmail.com>
DB/provisioner to be available, so add a way to skip the checkSigned-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
…ndlingThis commit addresses the requirements to:1. Comment out provisionerCloser.Close() in TestExecutorAutostartSkipsWhenNoProvisionersAvailable2. Remove the need for SkipProvisionerCheck by refactoring testsChanges:- Remove SkipProvisionerCheck field and logic from Executor- Remove SkipProvisionerCheck option from coderdtest.Options- Add proper provisioner daemon tags to match template requirements- Add helper functions for waiting for provisioner availability- Update tests to use real provisioner availability checks- Fix timing issues in provisioner staleness tests- Comment out provisioner close call to test proper behaviorThe test now correctly validates that provisioners remain availablewhen not explicitly closed, and uses the real hasAvailableProvisionerslogic instead of bypassing it.Signed-off-by: Callum Styan <callumstyan@gmail.com>
@cstyancstyanforce-pushed thecallum-autostart-no-provisioner branch from9971794 to78a8f5eCompareAugust 5, 2025 20:01
autobuild path have a valid provisioner available and pass anappropriate time.Time to the channel for triggering the build based onwhether the provisioner is supposed to be valid or staleSigned-off-by: Callum Styan <callumstyan@gmail.com>
@cstyan
Copy link
ContributorAuthor

Okay@deansheather thanks for your patience, I think this is finally ready for another review. Took quite a bit of digging with the help of Blink to find all the bits and pieces that had to be updated to get the tests working without theskipProvisionerCheck flag. I've done my own run through of the changes twice now but I may have still missed some small stuff, nit pick away 👍

The TL; DR of the changes is that we in tests which deal with autobuilds we need:

  • to create the test in a way where we also return the handle to the database instance
  • ensure the test creates a provisioner with the relevant tags for the workspace that will be used within that test case (in most cases this is just the defaultowner: "", scope: organization but there is a mechanism for using specific tags in at least one of the tests)
  • based on whether the autobuild should happen or not, we need to ensure we can retrieve the relevant provisioner and sest the scheduled tick time for the autobuild appropriately (should the provisioner be valid, or should it be stale)

TestExecutorAutostartSkipsWhenNoProvisionersAvailableSigned-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
any before thatSigned-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Comment on lines +59 to +65
p,err:=coderdtest.GetProvisionerForTags(db,time.Now(),workspace.OrganizationID,map[string]string{})
require.NoError(t,err)
// When: the autobuild executor ticks after the scheduled time
gofunc() {
tickCh<-sched.Next(workspace.LatestBuild.CreatedAt)
tickTime:=sched.Next(workspace.LatestBuild.CreatedAt)
coderdtest.UpdateProvisionerLastSeenAt(t,db,p.ID,tickTime)
tickCh<-tickTime
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

W.R.T the last comment from the previous review, this is what I'm referring to. Is this change (and other similar changes) necessary?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yes, AFAICT it is. Otherwise the test is flakey, it would only pass if you run the test withinStaleInterval seconds of the top of any hour.

When one of these tests starts, the provisioner has aLastSeenAt time oftime.Now() (sometimes + 1 second or so), butsched.Next(workspace.LatestBuild.CreatedAt) will return a value that is the top of the hour.

For example: right now if I comment out theUpdateProvisionerLastSeenAt line here, inhasValidProvisioner thepd.LastSeenAt time is2025-08-12 16:34:02.908042 +0000 UTC butt from thetickCh is2025-08-12 17:00:00 +0000 UTC. So in a real running deployment of Coder that provisioner would be considered stale.

This is the exact thing we were trying to solve for with the addition ofhasValidProvisioner. So any test case which utilized the autobuild functionality but needed to continue passing needed to update theLastSeenAt value. In the test I have added, which should see the provisioner as stale and then assert that there were no autobuild transitions initiated, we ensure theLastSeenAt time is far enough in the past that the provisioner is stale.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Ahhh I get it, because the autostart time is way in the future.

Perhaps a better option for these autostarty tests to set a value on the lifecycle executor likeTestIgnoreNoDaemons: true, and then just set it to true for these tests. Avoids having to get the provisioners and update them right before ticking, which feels like it could be racey

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Isn't that essentially just going back to what I had originally?#19067 (comment)

I guess we're doing the configuration in a cleaner way, but we'd still be setting that value to true for essentially all of these tests, which is what we wanted to change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah I think I may have looped... sorry. I think what you have now is good then 👍

new testSigned-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
nil hereSigned-off-by: Callum Styan <callumstyan@gmail.com>
Signed-off-by: Callum Styan <callumstyan@gmail.com>
@cstyancstyan merged commit6c902a7 intomainAug 15, 2025
26 checks passed
@cstyancstyan deleted the callum-autostart-no-provisioner branchAugust 15, 2025 15:50
@github-actionsgithub-actionsbot locked and limited conversation to collaboratorsAug 15, 2025
Sign up for freeto subscribe to this conversation on GitHub. Already have an account?Sign in.
Reviewers

@deansheatherdeansheatherdeansheather approved these changes

Assignees

@cstyancstyan

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Automatic builds should not be created if there are no provisioners with matching tags
2 participants
@cstyan@deansheather

[8]ページ先頭

©2009-2025 Movatter.jp