chore: add CODEOWNERS with basic setup

[jescalada]

Sets up a basic CODEOWNERS file.

@finos/git-proxy-maintainers Feel free to make these more granular! 👍🏼

[netlify]

✅ Deploy Preview for endearing-brigadeiros-63f9d0 canceled.

Name	Link
🔨 Latest commit	255fef5
🔍 Latest deploy log	https://app.netlify.com/projects/endearing-brigadeiros-63f9d0/deploys/698a1d2d7e1f60000883bb89

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 81.34%. Comparing base (6fb63d0) to head (255fef5).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1381   +/-   ##
=======================================
  Coverage   81.34%   81.34%           
=======================================
  Files          65       65           
  Lines        4648     4648           
  Branches      792      792           
=======================================
  Hits         3781     3781           
  Misses        852      852           
  Partials       15       15           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kriswest]

Let's have a chat about this at the next meeting before we merge it. We're going to need to check on the project settings with finos anyway

[kriswest]

@jescalada and @finos/git-proxy-maintainers I've tweaked this to always use the maintainers team as a fallback (you have to add the team to every line for that to work as it uses the last rule to match).

Please do add any other areas of the code you would like to be automatically added to reviews for.

[coopernetes]

Let's start with a code owners with just the first line. That'll solve the immediate concern of lack of reviews before merging.

Also I think we need a branch ruleset added with the "require an approval from someone other than the last person to push to a branch".

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-a-pull-request-before-merging

[coopernetes]

This is a logical OR (not AND). An approval from anyone in the maintainer team will satisfy the CODEOWNERS check. As such, I wonder if it's worth carving up the paths in this way considering that all the individuals in the FINOS team are the same mentioned in specific paths.

I think we can simply use the first line in the file only then handle specific parts of the code base via PR assignee or review requests.

We likely won't ever have committers with write access that aren't in the team.

[kriswest]

Fair enough. All this is achieving is review assignments that will already overlap with @finos/git-proxy-maintainers.

@jescalada if you're ok with keeping it simple we can apply that to the repo and I'll contact FINOS to make the settings changes for:

• Require review from Code Owners
• Require an approval from someone other than the last person to push to a branch

on the main branch.

[kriswest]

Also I think we need a branch ruleset added with the "require an approval from someone other than the last person to push to a branch".

This is best practice - but its also supremely annoying at times (merging suggestions from a review, or correcting a single missed period means you can't approve until someone else pushes). But I reluctantly agree that we need to set it.