Skip to content

Add code-generation & linter for system notification templates #36

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

Open
dannykopping opened this issue Aug 7, 2024 · 1 comment
Open

Comments

@dannykopping
Copy link
Collaborator

Ideally this code generation would produced a file called coderd/notifications/system_templates_generated.go:

// Workspace Events
var (
	TemplateWorkspaceDeleted = uuid.MustParse("f517da0b-cdc9-410f-ab89-a86107c420ed")
        ...
)

func AllSystemTemplates() []uuid.UUID {
  return {
    TemplateWorkspaceDeleted,
    ...
  }
}

// GetSystemTemplateByID returns the static contents of the requested system notification template.
func GetSystemTemplateByID(id uuid.UUID) database.NotificationTemplate {
  switch id {
    case TemplateWorkspaceDeleted:
      return database.NotificationTemplate {
        id: id,
        name: "Workspace Deleted",
        ...
      }
      ...
  }
}

NOTE: this must ONLY consider templates of kind=system.

We need this code-generation to solve a few problems:

  1. Tests that currently reference the notification_templates table won't need to use a real pg db anymore, speeding up tests
  2. AllSystemTemplates() will allow us to determine if we're missing any test cases
  3. We could generate golden test files to validate that a template produces precisely identical HTML + plaintext outputs for given inputs

Over and above this, we'll need a linter to validate that this new file is not out-of-sync with the database after migrations have run.

@dannykopping dannykopping changed the title Add code-generation to enumerate system notification templates Add code-generation & linter for system notification templates Aug 7, 2024
@BrunoQuaresma
Copy link

Right now, the delivery methods are smtp and webhook, but they are typed as regular string values in the codersdk. I think it would be great to have the method value as enum types in the SDK to ensure more reliable type checking in the BE and FE. I see they are enums in the database layer, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants