Helm backend

[skkra0]

Changes

/chart

• Created a chart for installing Spilo, based on this config from the spilo repository
  • The annotations field on the Chart.yaml is used for anvilops-specific metadata. For instance, under the key anvilops-values is some JSON that could be used for generating form fields for the chart on the frontend.
• Added some environment variables.

/openapi

• Added an endpoint for listing available AnvilOps charts. This returns some information on the Spilo chart.
• Added a third source for configs, helm.
• Request schemas for createApp and createAppGroup use the DeploymentConfig object.
  • This means the cpu and memory are formatted on the frontend.
• Split DeploymentConfig into two schemas, WorkloadConfigOptions(appType: "workload", source: git or image) and HelmConfigOptions(appType: "helm", source: helm).
  • WorkloadConfigOptions contains fields that are common between git and image configs e.g. port, subdomain, collectLogs. It also has either git config fields(source: "git", dockerfilePath, builder, repositoryId, etc) or image config fields(just imageTag).

/backend

/prisma

• Wrote a migration that adds new enums and creates a HelmConfig table, renames the DeploymentConfig table to WorkloadConfig and renames related items accordingly, then recreates DeploymentConfig. It contains an appType, which indicates whether to point to a WorkloadConfig or a HelmConfig. The configId on App and Deployment still point to a DeploymentConfig.

/db

• Added WorkloadConfig(create), GitConfig(create), and HelmConfig(create) types and updated the repos
  • I tried to largely hide how the different types of configs are actually represented in the database. The repos add the appropriate appType and source fields before returning config objects, and those fields are also used to decide how to insert a new config.
  • To avoid confusion, ids are omitted from the config objects. The id of a config is never used, since an update always results in a new Deployment and DeploymentConfig.

/lib

• Installed helm in the backend and wrote a module for running helm to retrieve and upgrade charts.
• Added some environment variables.

/service

• Updated handlers for helm and workload configs
• Wrote some -Service classes to simplify handler implementations
  • Moved config generation and validating logic to a class DeploymentConfigService. It is also responsible for picking up the commitHash and commitMessage of a git config.
  • Moved some logic for validating apps to a class AppService, which calls methods of DeploymentConfigService
  • Moved deployment and deployment canceling logic under a class DeploymentService
  • Many of the dependencies of the classes are passed into the constructor. This can be useful for testing, because instead of mocking modules, the test can just pass in fake versions of the objects used.
• Updated handlers accordingly
• Some endpoints error when the specified app has a Helm config, such as getAppLogs, -File

/frontend

• Organized components under /components/config and /components/diff
• Wrote types for form states and moved config / form state generation and formatting to /lib/form.ts
• Wrote placeholders for helm config-related components

To-do

• Test redeployments and project selection on anvilops-staging

[FluxCapacitor2]

Phew! This PR is gigantic. I've looked over everything but I haven't tested it myself yet.

I made some small changes that shouldn't change any behavior. Here is that diff if you'd like to review: https://github.com/PurdueRCAC/AnvilOps/compare/9eebc7979352eaa53f3d0ee9ef962cd7f0daa93f..ec207db68386c72474b82623e8cb45446bcf2883.

General notes:

1. I really like the idea of data-driven Helm templates that allow us to create forms with JSON and validate with JSON schemas. Great idea.
2. The refactoring generally looks good and I like the way you're doing dependency injection in src/service/helper/*.
3. Thanks for splitting off the frontend form stuff into separate files based on configuration area. That makes it a lot nicer to work with.
4. Administrators should have the ability to disable Helm deployments via environment variable. Maybe even Git and Image deployments too for completeness.
5. Of course, documentation needs to be updated to explain how administrators configure a Helm OCI repo & how users use the charts.
6. On the subject of documentation, I think the codebase is separated enough that we should document the directory structure somewhere.

Everything else is in individual review comments.

[FluxCapacitor2]

I assume this is temporary since users need a place to edit the Helm chart values, but if not, the whole tab should be hidden just like what I do for the Files and Logs tabs when they don't have any content.

[skkra0]

Yes, this is temporary