synced/coder
1
0
Fork 0
mirror of https://github.com/coder/coder.git synced 2025-07-13 21:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

adds support for workspace presets to the coderd database. Support in the API and web frontend will be added in subsequent pull requests. This is the smallest meaningful contribution that I could get passing tests for.

Browse Source 
* Add workspace preset tables to the database in a migration
* Add queries to manipulate workspace presets to the database
* Generate db related code for the newly added queries
* Implement new methods to satisfy the Querier interface in dbauthz, dbmem, dbmock and querymetrics
* Implement the required tests for dbauthz
* Update the audit table to track changes to the new column in workspace builds
This commit is contained in:
Sas Swart
2025-01-20 16:11:44 +00:00
parent 7f44189ed2
commit 2fca3693fc
17 changed files with 822 additions and 127 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
coderd/database/migrations/000288_workspace_parameter_presets.up.sql Normal file
View File

@ -0,0 +1,49 @@
CREATE TABLE template_version_presets
(
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
template_version_id UUID NOT NULL,
-- TODO (sasswart): TEXT vs VARCHAR? Check with Mr Kopping.
-- TODO (sasswart): A comment on the presets RFC mentioned that we may need to
-- aggregate presets by name because we want statistics for related presets across
-- template versions. This makes me uncomfortable. It couples constraints to a user
-- facing field that could be avoided.
name TEXT NOT NULL,
created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT CURRENT_TIMESTAMP,
-- TODO (sasswart): What do we need updated_at for? Is it worth it to have a history table?
-- TODO (sasswart): Will auditing have any relevance to presets?
updated_at TIMESTAMP WITH TIME ZONE,
FOREIGN KEY (template_version_id) REFERENCES template_versions (id) ON DELETE CASCADE
);
CREATE TABLE template_version_preset_parameters
(
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
template_version_preset_id UUID NOT NULL,
name TEXT NOT NULL,
-- TODO (sasswart): would it be beneficial to allow presets to still offer a choice for values?
-- This would allow an operator to avoid having to create many similar templates where only one or
-- a few values are different.
value TEXT NOT NULL,
FOREIGN KEY (template_version_preset_id) REFERENCES template_version_presets (id) ON DELETE CASCADE
);
ALTER TABLE workspace_builds
ADD COLUMN template_version_preset_id UUID NULL;
-- Recreate the view to include the new column.
DROP VIEW workspace_build_with_user;
CREATE VIEW
workspace_build_with_user
AS
SELECT
workspace_builds.*,
coalesce(visible_users.avatar_url, '') AS initiator_by_avatar_url,
coalesce(visible_users.username, '') AS initiator_by_username
FROM
workspace_builds
LEFT JOIN
visible_users
ON
workspace_builds.initiator_id = visible_users.id;
COMMENT ON VIEW workspace_build_with_user IS 'Joins in the username + avatar url of the initiated by user.';