You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We want different teams to have the ability to specify template
overrides for their specific controller or generated codebase.
There are a number of use cases where having the ability to specify
multiple "template search paths" will be useful.
Imagine that the ElastiCache ACK controller team wants to change their
boilerplate.txt content to mention something specific to ElastiCache.
Instead of adding a bunch of conditional statements to the code
generator or new fields to the generator configuration object (which is
already complicated), what if the maintainer team could add their custom
boilerplate text to a `templates/boilerplate.txt` file in the
elasticache-controller source repository and call `ack-generate`
commands like this:
```bash
CODE_GEN_REPO=$GOPATH/src/github.com/aws-controllers-k8s/code-generator
CONTROLLER_REPO=$GOPATH/src/github.com/aws-controllers-k8s/elasticache-controller
ack-generate apis --template-dirs $CONTROLLER_REPO/templates,$CODE_GEN_REPO/templates`
```
and the code generator would simply pick up the boilerplate.txt file in
the elasticache-controller repository and use that instead of the one in
the code-generator repo.
Another use case might be for a service controller team to experiment
with some Go code changes to the standard template files without needing
to modify any code in the code-generator repo itself.
For example, let's say that the S3 controller requires a radically different
set of Go code for its update code path than all the other controllers
and we want to test some ideas but not update the code-generator repo
itself. We could add a `templates/pkg/resource/sdk_update.go.tpl` file
to the s3-controller repository, rebuild the controller and iterate more
quickly.
Finally, there is the use case of having templates containing "hook
code" that is specific to one service controller. Imagine the following
generator config snippet:
```yaml
resources:
Broker:
hooks:
set_update_pre_build_update_request:
templatePath: hooks/sdk_update_pre_build_update_request.go.tpl
```
And in the service controller, we had a file
`templates/hooks/sdk_update_pre_build_update_request.go.tpl` with the
contents:
```go
if err := rm.requeueIfNotRunning; err != nil {
return nil, err
}
```
We could call the `ack-generate` passing in multiple template search
base paths like shown above and in this way, we could have
service-specific code placed inside the service controller source
repositories and have our code generation be much more flexible.
&optDryRun, "dry-run", false, "If true, outputs all files to stdout",
102
102
)
103
-
rootCmd.PersistentFlags().StringVar(
104
-
&optTemplatesDir, "templates-dir", defaultTemplatesDir, "Path to directory with templates to use in code generation",
103
+
rootCmd.PersistentFlags().StringSliceVar(
104
+
&optTemplateDirs, "template-dirs", defaultTemplateDirs, "Paths to directories with templates to use in code generation. Note that the order in which directories is specified will be used to provide override functionality.",
105
105
)
106
106
rootCmd.PersistentFlags().StringVar(
107
107
&optServicesDir, "services-dir", defaultServicesDir, "Path to directory to output service-specific code",
0 commit comments