feat: mark prebuilds as such and set their preset ids #16965
Conversation
7e062e2 to
51773ec
Compare
| build, err := client.CreateWorkspaceBuild(ctx, workspace.ID, codersdk.CreateWorkspaceBuildRequest{ | ||
| TemplateVersionID: version.ID, | ||
| Transition: codersdk.WorkspaceTransitionStart, | ||
| TemplateVersionPresetID: presets[0].ID, |
There was a problem hiding this comment.
What is ID here, UUID? Should we rely on a value that is human readable instead?
There was a problem hiding this comment.
This ID is randomly generated by the database.
There was a problem hiding this comment.
Let's say, I'm a template admin and want to modify the template with presets. I'm pushing a new template revision, it gets a new template version name and new template version ID. Does it happen the same for template version presets? will they get new IDs on every template version push, or will IDs be reused?
BTW we can move this to slack to keep things rolling.
There was a problem hiding this comment.
Does it happen the same for template version presets?
Yes it does.
Presets are associated to a template version, so a new template version will create new preset entries.
| build, err := client.CreateWorkspaceBuild(ctx, workspace.ID, codersdk.CreateWorkspaceBuildRequest{ | ||
| TemplateVersionID: version.ID, | ||
| Transition: codersdk.WorkspaceTransitionStart, | ||
| TemplateVersionPresetID: presets[0].ID, |
There was a problem hiding this comment.
Let's say, I'm a template admin and want to modify the template with presets. I'm pushing a new template revision, it gets a new template version name and new template version ID. Does it happen the same for template version presets? will they get new IDs on every template version push, or will IDs be reused?
BTW we can move this to slack to keep things rolling.
| build, err := client.CreateWorkspaceBuild(ctx, workspace.ID, codersdk.CreateWorkspaceBuildRequest{ | ||
| TemplateVersionID: version.ID, | ||
| Transition: codersdk.WorkspaceTransitionStart, | ||
| TemplateVersionPresetID: presets[0].ID, |
There was a problem hiding this comment.
Does it happen the same for template version presets?
Yes it does.
Presets are associated to a template version, so a new template version will create new preset entries.
| Type: &proto.Response_Plan{ | ||
| Plan: &proto.PlanComplete{ | ||
| Presets: []*proto.Preset{{ | ||
| Name: "test", |
There was a problem hiding this comment.
I'm wary of creating such minimal definitions here and in coderd/workspacebuilds_test.go (i.e. ones that do not have other fields like params); this does not reflect a legitimate use of presets.
There was a problem hiding this comment.
Presets are allowed to have 0 parameters. This is to enable prebuilds on templates in which provisioning times are not contingent on parameters having certain values, which is a legitimate use case.
We're also not asserting anything that depends on these parameters in any way. I can add some, but I'm not sure what specifically to add that you find find beneficial? Should I just contrive a few parameters for good measure?
|
|
||
| presets, err := client.TemplateVersionPresets(ctx, version.ID) | ||
| require.NoError(t, err) | ||
| require.Equal(t, 1, len(presets)) |
There was a problem hiding this comment.
We're only ever testing a single preset, and I think there's some risk associated with that. Can you expand this, or add another test which uses multiple presets please?
| @@ -107,6 +107,8 @@ type CreateWorkspaceBuildRequest struct { | |||
|
|
|||
| // Log level changes the default logging verbosity of a provider ("info" if empty). | |||
| LogLevel ProvisionerLogLevel `json:"log_level,omitempty" validate:"omitempty,oneof=debug"` | |||
| // TemplateVersionPresetID is the ID of the template version preset to use for the build. | |||
There was a problem hiding this comment.
Nit: this comment is a bit redundant.
| // TemplateVersionPresetID is the ID of the template version preset to use for the build. | |
| // TemplateVersionPresetID is the ID of the selected preset, if available. |
| if metadata.GetIsPrebuild() { | ||
| env = append(env, provider.IsPrebuildEnvironmentVariable()+"=true") | ||
| } | ||
|
|
There was a problem hiding this comment.
On second thought, I'm thinking maybe we should always include the env for the absence of doubt:
| if metadata.GetIsPrebuild() { | |
| env = append(env, provider.IsPrebuildEnvironmentVariable()+"=true") | |
| } | |
| env = append(env, fmt.Sprintf("%s=%v", provider.IsPrebuildEnvironmentVariable(), metadata.GetIsPrebuild())) |
This pull request closes coder/internal#513