MR: Pending <!-- The first line of this issue description must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, 3. If there are multiple MRs: ``` MRs: - <MR 1 link with trailing +>` - <MR 2 link with trailing +>` - ... ``` 4. `MR: No MR` ...and the first description line of the MR should be `Issue: <Issue link with trailing +>` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description This discussion https://gitlab.com/gitlab-org/gitlab/-/merge_requests/166343#note_2121215349 spun up an important conversation on how we validate models. ## TLDR: ### What we realised some validations in `ee/app/validators/remote_development/` mirror existing structural and type validations that `ee/app/validators/json_schemas/\*.json` already ensure. ## Acceptance Criteria We would need to clean up the existing validators that have redundant checks and update our docs to reflect how we handle custom validations - [ ] Asses the custom validator classes for redundant checks (those already present in a corresponding JSON schema) and remove them - [ ] Add model-level tests to compensate for those cleaned from the validator (you could use rspec table testing syntax to reduce boilerplate/verbosity example [here](https://gitlab.com/gitlab-org/gitlab/-/blob/f2b8fbd01d0409de489ad82792522b5561b15838/ee/spec/models/remote_development/workspaces_agent_config_spec.rb#L139)). - [ ] Update workspace docs if necessary on the model validation pipeline, i.e utilize the JSON schema for as much validation as possible given the context, then for more complex logical validations that JSON spec cannot handle, use a validator class <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://handbook.gitlab.com/handbook/engineering/development/dev/create/remote-development/#-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->