@nawazkh: The label(s) kind/fix cannot be applied, because the repository doesn't have them.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 52.44%. Comparing base (eb432ed) to head (77f9e4b).
Report is 12 commits behind head on main.

@@           Coverage Diff           @@
##             main    #5390   +/-   ##
=======================================
  Coverage   52.44%   52.44%           
=======================================
  Files         272      272           
  Lines       29349    29349           
=======================================
  Hits        15391    15391           
  Misses      13152    13152           
  Partials      806      806           

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

lgtm, comparing against AWS' version: https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/PROJECT

found more things to be added
/hold

/unhold
Ready for review.

LGTM label has been added.

/lgtm

Although I'm going to be honest--I don't know what tooling consumes this file or where this YAML is used. Naively, it looks correct now, but can anyone clue me in?

TL;DR: PROJECT file is mostly use to showcase the list of APIs the project maintains.
It is an auto-generated file created on using kubebuilder <command>.
We should look into restoring this functionality. Might involve refactoring the CAPZ code.

Here's what I found.

• PROJECT file, also known as PROJECT config file is created when Kubebuilder is used to init project and/or add/edit APIs.
• Looking at the blame of this file, looks like PROJECT file was put in place long ago.
  And maybe somewhere along the way in the development of CAPZ we decided to opt for more custom approach of scaffolding CAPZ APIs, dropping (?) kubebulider way of scaffolding APIs. If we were to use kubebuilder --create api --group ... we would see an update to the PROJECT file.
• Reference to PROJECT file in kubebuilder documentation: https://book.kubebuilder.io/reference/project-config#project-config

Experiment: I tried creating my own API for a custom resource using Kubebuilder

1. Kubebuilder wanted me to move main.go to ./cmd/.
2. After doing that, kubebuilder did setup the CRD, controller, controller_test, suite_test, api.. etc artifacts. But is also added some new dependencies to the project (updated go.mod).
3. kubebuilder init did not finish successfully, but did generate a lot of artifacts in the project. If we were to go down this path, we want to refactor the code.

This short experiments hints me that CAPZ might have wanted to have more control over their APIs and might have moved away from kubebuilder. OR maybe, we did not add any APIs using kubebuilder create api in a while ?

/cc @willie-yao

I noticed that the ASO managed cluster types are not included here. Is there a reason for that?

I learned that PROJECT file is supposed to maintain a list of GVKs that are owned & maintained by the project.
So the ones like ASO* and AzureServicePrincipals are GVKs that CAPZ does not own, instead refers it or uses them as dependent resources.
Therefore we would not want to have ASO* resources in PROJECT file. Ideally, we should be finding ASO GVKs in ASO repo.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: willie-yao

The full list of commands accepted by this bot can be found here.

The pull request process is described here