Run the following command
REPO_ROOT="$(git rev-parse --show-toplevel)"
cd $REPO_ROOT/dev/tools/controllerbuilder
go run . generate-mapper \
--service google.storage.v1 \
--api-version "storage.cnrm.cloud.google.com/v1beta1"
Note: We suggest using the same proto for your mock GCP and for you type-generation tool to generate the Config Connector API and mapper to avoid mismatch in schema definitions. There are some exceptions where you need to replace the proto go package.
If no comments marked MISSING
and all the mapper functions look good, you are done. You can move to “Add the controller” (step 4).
If you need manual changes to some methods, remove the method or/and the MISSING
comment from the generated code and move to the next step (step 3.2).
Create a <resource>_mappings.go
underpkg/controller/direct/<service>
only if the auto-generated code cannot fulfill the mappings.
If you have a lot of fields that need to be manually written, you can split the work into several PRs, just keep the MISSING
comments for reference. Also, comment out the code you plan to update with /*NOTYET*/
comments
- Move the code that needs manual change from
<resource>_generated.mappings.go
to<resource>_mappings.go
- Follow the naming convention as the auto-generated code. You shall have two methods
<field>_ToProto
and<field>_FromProto
- Remove the
MISSING
comment
If you are developing a Beta or more stable resource version, you should meet the following requirements:
- No
MISSING
comments left in the code - No
/*NOTYET*/
comments left in the code. - For Beta resources, a fuzzer test exists for both Spec and Status of the resource. Example
- Each mapper method shall reflect in the
_http.log
as the value fromcreate.yaml
andupdate.yaml
recorded in the_http.log
POST and PUT/PATCH method.