Propose creating an OTEL Collector GitHub Template

[adrielp]

Is your feature request related to a problem? Please describe.

This request serves to propose the creation of a GitHub Template repository for creating OpenTelemetry Collector distributions easily as described here in issue #8555.

Describe the solution you'd like

As someone who created and maintains a distribution, and encourages others to build distributions following the Principle of Least Privilege, I'd like to see an easy way to create OTEL Collector distributions that are compliant with the definition decided upon in #8555.

The idea here is to create a template repository which contains all the core files, structure, and utilities to build and maintain your own distribution. I think it would look something like:

.
├── .github
│   └── .... # directory for GitHub Actions w/ default publishing & versioning workflows
├── .goreleaser.yaml # default GoReleaser configuration file for build and publishing
├── Dockerfile # default scratch docker image
├── LICENSE # Apache 2.0 License matching OpenTelemetry
├── Makefile
├── Makefile.Common
├── README.md
├── config
│   ├── config.yaml # default OTEL Collector configuration file
│   └── manifest.yaml # default OTEL Collector build manifest file for OCB
├── connector
│   └── .... # directory for custom connectors
├── extension
│   └── .... # directory for custom extensions
├── go.mod
├── go.sum
├── internal
│   ├── components
│   │   └── components.go # for building go.* at the root of repo w/ custom components
│   └── tools # tool.go pattern for managing third party go tools
│       ├── Makefile
│       ├── go.mod
│       ├── go.sum
│       ├── tools.go # tools like OCB to be installed & versioned
│       └── tools_test.go
├── receiver
│   └── .... # directory for custom receivers
├── exporter
│   └── .... # directory for custom exporters
├── processor
│   └── .... # directory for custom processors
├── renovate.json # default renovate.json for dep updates w/ OCB
└── versions.yaml # versions.yaml for multi-mod versioning

Making it easy and supported to build a collector distribution would likely help with adoption, help build collectors consistently, and enable others to build collectors with components from vendor distributions. Additionally, because they're built consistently, it would help end-users understand what components are in which distribution, etc.

Describe alternatives you've considered

Could also be done through the go templating patterns already in place and hosted alongside the builder utility. Dual purpose could add this as part of the test bed.

[jpkrohling]

I'm in favor of this one as well.

[rogercoll]

+1

The current Makefile strategy is really helpful when developing new components/distribution (generate, test, format, etc.), it also eases keeping custom components align with the upstream best practices (vulnerabilities, lint, tooling, etc.).