Raising this issue to help reach an engineering decision on what is the best way for this project to install/leverage tooling
for supporting various developer workflows such as generating license for files, using linters and more...
Sharing three ways this is done in most projects today -
- Use a build container which comes pre-installed with all tooling needed for developer workflows.
Istio and Envoy use this method today
Pros
- Easy to add/rm tools for the project
- No binary artifacts
Cons
- Some devs prefer running tools natively rather than in a container since they are slower
- Docker builder docker image artifact
- Use an indirection of replacing the tool name with a local script that lives in
hack/ . The script can do
clever things like either call the tool binary directly, or call the docker image of the tool directly.
This approach is used in Contour today
Pros
- Script allows for flexibility
Cons
- Hard for the dev (user) and well as code owners to keep track of exact logic
- Install the tool binary into the local
bin/ directly using a make target and use it
This approach is used by Kubebuilder based projects
Pros
- The projects installs all the tooling with the right version into the local
bin directory
making the project
- The tooling installation and the dev workflow logic (make targets) live close to each other
Cons
- Binary artifacts
Raising this issue to help reach an engineering decision on what is the best way for this project to install/leverage tooling
for supporting various developer workflows such as generating license for files, using linters and more...
Sharing three ways this is done in most projects today -
Istio and Envoy use this method today
Pros
Cons
hack/. The script can doclever things like either call the tool binary directly, or call the docker image of the tool directly.
This approach is used in Contour today
Pros
Cons
bin/directly using amaketarget and use itThis approach is used by Kubebuilder based projects
Pros
bindirectorymaking the project
Cons