Skip to content

feat: add endpoint for resolving autostart status #10507

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

Merged
merged 9 commits into from
Nov 9, 2023
Merged

Conversation

sreya
Copy link
Collaborator

@sreya sreya commented Nov 3, 2023

This PR adds an endpoint for determining whether autostart is possible for a workspace. It takes into account whether the template mandates automatic updates or if workspace has opted in to automatic updates. This provides the backend plumbing necessary for #10098.

A separate PR will be opened to handle the frontend implementation.

@sreya sreya force-pushed the jon/autoupdatestart branch from 9abeaaf to 872e214 Compare November 8, 2023 02:22
@sreya sreya requested a review from spikecurtis November 8, 2023 03:25
@sreya sreya changed the title feat: add parameter resolution to workspace endpoint feat: add endpoint for resolving autostart status Nov 8, 2023

t.Run("OK", func(t *testing.T) {
t.Parallel()
ownerClient := coderdtest.New(t, &coderdtest.Options{IncludeProvisionerDaemon: true})
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you do this without a ProvisionerDaemon following the new dbfake paradigm introduced here: #10426 ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I can make this change but it's not as trivial as it sounds especially because of parameters. Once I finish up this feature I'm planning on helping refactor existing tests using dbfake. Do you care if we push it for now?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm wary of shipping a feature with a "chore" task leftover that we pinky-promise to fix up soon. Once the feature is shipped it's real easy to just put off the chore indefinitely. Even if you created a GitHub ticket, we auto-close stale issues! I'm not questioning your sincerity, but the road to hell is paved with best intentions.

I think debt is a good analogy in this case. You're saying we should take out a loan here. What's so important about shipping this change now such that we want to take the risk of not fixing the tests? Flaky tests are like, the biggest thing on developer's mind judging by our conversation at the offsite.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah agreed, per our offline conversation I'm going to refactor these in a separate PR.


ownerClient, owner := coderdenttest.New(t, &coderdenttest.Options{
Options: &coderdtest.Options{
IncludeProvisionerDaemon: true,
Copy link
Contributor

Choose a reason for hiding this comment

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

ditto, should use dbfake rather than a provisioner daemon

@sreya sreya requested a review from spikecurtis November 8, 2023 17:00
@sreya sreya mentioned this pull request Nov 8, 2023
8 tasks
@sreya sreya merged commit e23873f into main Nov 9, 2023
@sreya sreya deleted the jon/autoupdatestart branch November 9, 2023 05:24
@github-actions github-actions bot locked and limited conversation to collaborators Nov 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants