feat: add provisioner job metadata #16454
Conversation
This change adds metadata to provisioner jobs to help with rendering related tempaltes and workspaces in the UI.
coderd/database/dbmem/dbmem.go
Outdated
| } | ||
| templateVersionID := input.TemplateVersionID | ||
| if input.WorkspaceBuildID != nil { | ||
| workspabeBuild, err := q.getWorkspaceBuildByIDNoLock(ctx, *input.WorkspaceBuildID) |
| -- We should always have a template version, either explicitly or implicitly via workspace build. | ||
| template_versions tv ON tv.id = CASE WHEN pj.input ? 'template_version_id' THEN (pj.input->>'template_version_id')::uuid ELSE wb.template_version_id END |
There was a problem hiding this comment.
Is the issue here that either input.template_version_id or wb.workspace_build_id can be null, so we're trying to account for both possibilities?
There was a problem hiding this comment.
Not quite. Both could be null in the future, all we need to do is add a new provisioner job type/input.
What we do get currently though, assuming correct input, is that there always exists a template version either directly (id) or indirectly (workspace build). This makes sure we join the template version (and thus, template) in both cases.
And in the case that neither exists in input, the template and template version info will be null.
There was a problem hiding this comment.
Gotcha. It might be good to add some querier tests for these eventualities just to make sure we're not surprised in the future.
| LEFT JOIN | ||
| workspaces w ON wb.workspace_id = w.id |
There was a problem hiding this comment.
Is it possible that wb.workspace_id will be NULL here?
There was a problem hiding this comment.
Yes, if the job is a template version import.
coderd/provisionerjobs_test.go
Outdated
| assert.Equal(t, job2.Metadata, &codersdk.ProvisionerJobMetadata{ | ||
| TemplateVersionName: version.Name, | ||
| TemplateID: template.ID, | ||
| TemplateName: template.Name, | ||
| TemplateDisplayName: template.DisplayName, | ||
| WorkspaceID: &w.ID, | ||
| WorkspaceName: w.Name, | ||
| }) |
There was a problem hiding this comment.
I think it might be useful to assert the provisioner job metadata:
- on template import
- on template version create
- on workspace build
There was a problem hiding this comment.
I added a case for template import, I don't know of any distinction for "version create" so I skipped that.
| @@ -39,6 +45,14 @@ | |||
| "workspace_build_id": "========[workspace build ID]========" | |||
| }, | |||
| "type": "workspace_build", | |||
| "metadata": { | |||
| "template_version_name": "===========[version name]===========", | |||
| "template_id": "===========[template ID]============", | |||
There was a problem hiding this comment.
Which party will consume the metadata later? I mean, is it human or machine?
If human, perhaps we can remove template_id and workspace_id?
There was a problem hiding this comment.
Either machine or human. For now, this is needed in the UI to show and link relevant workspace/template. I'll defer to @BrunoQuaresma as to what's needed, but I don't see any harm in keeping the IDs in? If I was an admin debugging provisioner jobs, I'd imagine it could come in handy.
There was a problem hiding this comment.
I would agree with leaving this information available in the JSON output. This is my general experience with other CLI tooling as well (e.g. kubectl or docker) -- if you need all the info, dump the JSON or YAML and read it.
There was a problem hiding this comment.
The reason why I raised this comment is my concern about the response size. IMHO we could always add these properties later, but if you find these could be useful for debugging then leave them as is. I understand that admins don't use them for troubleshooting but rather default to template/template version/workspace names, and IDs seem to be internal references.
There was a problem hiding this comment.
Response size is a valid concern @mtojek, especially considering we didn't limit the response of this endpoint previously. In the regular response size (say 50 entries), these UUIDs are quite harmless and the endpoint isn't going to be very actively used. I haven't personally needed to debug provisioner jobs so I went for more rather than less, but happy to go either way here (assuming @BrunoQuaresma doesn't need the IDs).
There was a problem hiding this comment.
BTW @BrunoQuaresma is out today, and since it is not a huge issue I don't have anything against merging it as is 👍
This change adds metadata to provisioner jobs to help with rendering
related tempaltes and workspaces in the UI.
Updates #15084