Add formatting and validation for free-form fields

[Avish34]

The changes are intended to create validators for all the free-form fields. Please find the details of the validation of different field below.

• Repository.Source: only github and gitlab is accepted.
• Repository.Url - It should be a valid github or gitlab URL. Created regex for both.
• Server.Name - Max 200 char can be there. Reverse domain name verification is part of another PR (not owned by me).
• Package.Name - Max 200 char and no spaces.
• Server.Description - Max 100 char.
• Remote.Url - It should be valid URL.

TODOs

• Respository.ID - It's a int64 as mentioned in the github API docs. I will confirm again and make the relevant changes.

Motivation and Context

The motivation was to make the code clean and add base code for more validator for different objects like Repository etc.
#97

How Has This Been Tested?

It's tested via UTs. Added UT's for all the validations.

Breaking Changes

Yes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[codecov-commenter]

Codecov Report

❌ Patch coverage is 28.57143% with 10 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/validators/validators.go	0.00%	10 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Avish34]

@tadasant please review.

[domdomegg]

[EDIT: see comment below...]

I think where possible, I'd want to push this into the JSON schema spec as much as possible - this means:

• it's well documented to users of the spec
• we have fewer places we're defining the spec
• it's automatically validated by Huma (I think?)

Of course there will be exceptions to this where we really can't do it with JSON schema. But a lot of this I think could be replicated with e.g. length or regex requirements on the JSON schema etc.

[domdomegg]

Hmm actually just read up on #97, and that maybe we only want this to be on the official registry API spec (rather than the generic registry API spec). Based on @.tadasant's comment:

First step is to enumerate and add those constraints to the registry-schema.json. We don't want them in the core schema.json - the latter is fine to be more permissive.

I guess in that case the approach you've gone for here is fine - I'll leave it up to @tadasant to decide / review :)

[rdimitrov]

@domdomegg - isn't it preferred to still have the validation in the schema even if it's just for registry-server.json?

[domdomegg]

@rdimitrov possibly true? I guess then it'd be harder to take the official-registry-api-schema.json and turn it into the registry-api-schema.json. But maybe this is fine and/or we shouldn't maintain them this way.

[Avish34]

@domdomegg / @tadasant can we conclude on the discussion whether we want to add the validation in the spec and let huma handle it or we should go ahead with the code based validation? It's fine if we need more time to think it through.

[tadasant]

Sorry I'm well behind on reviews and discussions and trying to focus where I'm blocking @domdomegg - trust his call on this one if he wants to jump ahead and get this merged (otherwise I will get to this eventually, just will be slow)

This is correct:

maybe we only want this to be on the official registry API spec

The intent is for this formatting/validation to only apply to the official registry. Most importantly at publication-time (we don't want people publishing data that is noncomformant to these expectations)

I haven't yet formed an opinion on how that cascades to the implementation here

[Avish34]

No worries @tadasant, take your time. @domdomegg you can also review if you want to.

[domdomegg]

Okay I've had a think about this, and my conclusion is that I think it doesn't matter too much either way 😅

I have a weak preference towards doing it as schema annotations in huma, rather than custom code validations. I think this documents it better for users of the API, and usually is less verbose/puts all the schema info in one place.

I'd be happy to accept this PR, or one doing it with schema annotations, once the code is cleaned up a little (e.g. linting and tests pass). @Avish34 are you good to take up implementing it one of these ways, then pinging me once you have CI passing?