CICD: Move OWNERS to .github/CODEOWNERS

[chicks-net]

Summary

Fixes #3978

GitHub requires the CODEOWNERS file to be located in the .github/ directory (or repository root with that exact name) to function properly. This PR moves OWNERS to .github/CODEOWNERS and updates all references throughout the codebase.

Changes Made

• Renamed OWNERS → .github/CODEOWNERS
• Updated .gitattributes to reference the new location
• Updated build/generate/ownersFile.go to generate the file in the correct location
• Updated documentation in writing-providers.md to reference .github/CODEOWNERS
• Added Tim as global owner
• EXOSCALE: Giza is now maintainer and the generated feature flags are updated.

Test Plan

• Ran /bin/generate-all.sh to verify the generator creates the file in the new location
• Verified all file references were updated
• Checked that the file move preserves all content

% git grep OWNERS
.gitattributes:.github/CODEOWNERS eol=lf
build/generate/ownersFile.go:   file, err := os.Create(".github/CODEOWNERS")
documentation/advanced-features/writing-providers.md:  * `CODEOWNERS`

🤖 Generated with Claude Code

[tlimoncelli]

Hello friend!

Github is complaining that the people in CODEOWNERS do not have write permission. Each one gets an error such as:

Unknown owner on line 31: make sure @juliusrickert exists and has write access to the repository
providers/hostingde @juliusrickert

They don't have write permission because the current policy (from my employer) is that I have to approve any merge to main. Is there some other way to comply with the policy but give people write access?

[chicks-net]

Hello friend!

Howdy sir! 🙇

Github is complaining that the people in CODEOWNERS do not have write permission. Each one gets an error such as:

Unknown owner on line 31: make sure @juliusrickert exists and has write access to the repository
providers/hostingde @juliusrickert

They don't have write permission because the current policy (from my employer) is that I have to approve any merge to main. Is there some other way to comply with the policy but give people write access?

Oh dear, github policy and stackexchange policy are not playing nicely together here. 😭 Changing the policies is not a practical option. Effectively this means that the CODEOWNERS features won't work for us. I've given this some thought and research and suggest:

1. Going ahead with the rename to CODEOWNERS is moving things in a more correct direction even if it isn't going to do much for us as-is.
2. We should probably add in a comment to the generated CODEOWNERS file indicating the policy limitation.
3. The hoped-for functionality can be regained with https://github.com/marketplace/actions/assign-reviewers if we want to stick with CODEOWNERS format for the config or https://github.com/marketplace/actions/auto-request-review if we want to generate a new format too.

Would adding the comment be enough to make this PR worth landing? I'm happy to work on the other github actions in this PR or a new one.

[chicks-net]

This is unblocked now that we're in the new github org. 😄

[chicks-net]

I rebased and fixed the one issue @cafferata noticed. I don't think I caused any of the CI jobs failing.

How does it look now?

[chicks-net]

CI Failure Analysis

All 7 failing checks share a single root cause: go.mod / go.sum need updating. Running go mod tidy locally produces changes in both files. Every red check is a downstream victim:

Failed Check	Error
go mod tidy	Dirty git status: go.mod and go.sum changed after go mod tidy
go fmt	go: updates to go.mod needed; to update it: go mod tidy
go fix	Same
go generate	Same
fmtjson (build)	go build fails: go: updates to go.mod needed
build (unit tests)	Same
golangci-lint	no go files to analyze: running go mod tidy may solve the problem

The fix is straightforward: run go mod tidy, commit the resulting changes, and push. Should I include that commit in this PR?

[cafferata]

I would advise keeping go.mod / go.sum changes out of scope of this PR. Those tend to pull in unrelated dependency bumps that make the diff harder to review and bisect later. A separate PR (or a rebase onto a fresh main that already has them) would be cleaner.

[chicks-net]

I would advise keeping go.mod / go.sum changes out of scope of this PR. Those tend to pull in unrelated dependency bumps that make the diff harder to review and bisect later. A separate PR (or a rebase onto a fresh main that already has them) would be cleaner.

Sounds good to me. I'd prefer to keep the PRs more focused and not glom unrelated changes onto them just so we can fix the GHAs.

I think this is ready for review again. 😁

[TomOnTime]

Suggestion: Once we merge this, we should create a new "role" called "provider" which has just enough privs to update labels and be a reviewer. (I assume that's possible.) However they shouldn't have merge privs. (I should be the only one that can merge to main for now)

[chicks-net]

Suggestion: Once we merge this, we should create a new "role" called "provider" which has just enough privs to update labels and be a reviewer. (I assume that's possible.) However they shouldn't have merge privs. (I should be the only one that can merge to main for now)

100% agree. This is exactly what I was hoping for.

[TomOnTime]

FYI: #4242 should fix the go mod tidy stuff for you.