fix: Enforce repository name length limit in dialogs

[zkoppert]

Pull Request

Proposed Changes

fixes #135

This pull request limits the length of repository names in the application. The changes ensure that both the creation and editing of mirrors enforce a maximum length of 100 characters for the repository name. This is achieved through changes in the frontend and backend validation schemas.

For Reviewers

• I want to add tests but wasn't able to find where we are already testing the mirror creation process. Is there a good spot to add a test for this? Maybe test/app.test.ts?
• Did I miss any spots that also need the limit enforced?

Readiness Checklist

Author/Contributor

• [ ] If documentation is needed for this change, has that been included in this pull request
• [x] run npm run lint and fix any linting issues that have been introduced
• [x] run npm run test and run tests
• [ ] If publishing new data to the public (scorecards, security scan results, code quality results, live dashboards, etc.), please request review from @jeffrey-luszcz

Reviewer

• [x] Label as either bug, documentation, enhancement, infrastructure, maintenance, or breaking

[ajhenry]

Nice! You can add tests for the backend like in this example. Just pass your invalid value here

https://github.com/github-community-projects/internal-contribution-forks/blob/e5dcd387551976576228137a7357c01187ad5eb2/test/server/repos.test.ts#L245-L256

You can use this test case to base it on

[zkoppert]

✅ Added a test for going over the limit cc79061 👎🏻 Not happy with how the error.message looks in the expect statement. It's a multiline string. Open to any ideas/suggestions/improvements!

[ajhenry]

@zkoppert I think it’s good as is but you can always do a .includes("String must contain at most 100 character(s)") on the error message

[zkoppert]

✅ More readable test assertion

[zkoppert]

I checked out the contributing doc and didn't see anything about deploying the change. Should I deploy before merge/after merge/not at all?

[sutterj]

We've been deploying after merges. The deployment is from the internal repo which is (I think) why it's not mentioned here.