Skip to content
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

feat: allow presets to define prebuilds #373

Merged
merged 7 commits into from
Apr 7, 2025
Merged

feat: allow presets to define prebuilds #373

merged 7 commits into from
Apr 7, 2025

Conversation

SasSwart
Copy link
Contributor

@SasSwart SasSwart commented Apr 3, 2025

This PR closes #362

@SasSwart SasSwart requested a review from mafredri April 3, 2025 12:08
Copy link
Member

@mafredri mafredri left a comment

Choose a reason for hiding this comment

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

I think the docs could be improved a bit but otherwise LGTM 👍🏻

Copy link
Member

@johnstcn johnstcn left a comment

Choose a reason for hiding this comment

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

At the risk of opening a can of worms, I think it would be valuable to add or modify an existing integration test for this -- even if it just asserts no prebuilds exist right now.

@@ -83,6 +91,11 @@ func workspaceDataSource() *schema.Resource {
Computed: true,
Description: "The access port of the Coder deployment provisioning this workspace.",
},
"prebuild_count": {

Choose a reason for hiding this comment

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

is_prebuild & prebuild_count looks the same to me, what's the point to have both?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This seems to be duplication, yes. We could probably get rid of "is_prebuild" and just check the count. Looking at the rest of the code, we are following the pattern that was set by the "transition" and "start_count" parameters. They have the same relationship.

I'm not sure whether to remove "is_prebuild" or keep it.

Copy link

@evgeniy-scherbina evgeniy-scherbina Apr 4, 2025

Choose a reason for hiding this comment

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

I don't like neither prebuild_count nor start_count. But probably there is some reason we're using, I'm not aware of.
My guess is we're using start_count to map transition statuses, like:

  • stop: 0
  • start: 1
    etc...

Also looks like there is some duplication here as well:

  • start_count
  • transition

But I don't know why it's needed.

We can ask original author of this approach with start_count, transition?
Maybe it was done in a rush, and there is no point to continue using this approach.

prebuildCount = 1
_ = rd.Set("is_prebuild", true)
}
_ = rd.Set("prebuild_count", prebuildCount)
Copy link

@evgeniy-scherbina evgeniy-scherbina Apr 4, 2025

Choose a reason for hiding this comment

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

nit: I'd rather write it like this:

if prebuild == "true" {
	_ = rd.Set("is_prebuild", true)
	_ = rd.Set("prebuild_count", 1)
} else {
	_ = rd.Set("is_prebuild", false)
	_ = rd.Set("prebuild_count", 0)
}

I think it's more logical, but it's not a big deal

@@ -121,3 +139,7 @@ func workspaceDataSource() *schema.Resource {
},
}
}

func IsPrebuildEnvironmentVariable() string {
return "CODER_WORKSPACE_IS_PREBUILD"

Choose a reason for hiding this comment

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

I guess it can be const instead of func, but up to you

}

func workspacePresetDataSource() *schema.Resource {
return &schema.Resource{
SchemaVersion: 1,

Description: "Use this data source to predefine common configurations for workspaces.",
Description: "Use this data source to predefine common configurations for coder workspaces. Users will have the option to select a defined preset, which will automatically apply the selected configuration. Any parameters defined in the preset will be applied to the workspace. Parameters that are not defined by the preset will still be configurable when creating a workspace.",
ReadContext: func(ctx context.Context, rd *schema.ResourceData, i interface{}) diag.Diagnostics {
var preset WorkspacePreset
Copy link

@evgeniy-scherbina evgeniy-scherbina Apr 4, 2025

Choose a reason for hiding this comment

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

@SasSwart btw: I just noticed code in the ReadContext is basically no-op?
It reads data and then forgets them.
Probably it's fine if main goal is to send this data downstream to provisioner

But still what is the purpose of this code?

  • is it for validation purposes? But I'm not sure maybe validations happens earlier?
  • is it for helping debugging in the future?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Most of the decoding is defunct, yes. I've removed it.
I don't think we should rely on this for validation.
We define a schema below, which Terraform already uses for validation.
I've removed the defunct code here: #376

@SasSwart SasSwart merged commit ef92eea into main Apr 7, 2025
6 checks passed
@SasSwart SasSwart deleted the jjs/363 branch April 7, 2025 06:20
@github-actions github-actions bot locked and limited conversation to collaborators Apr 7, 2025
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.

Add support for defining prebuilds on workspace_presets
4 participants