miniscruff
Allow components to be associated with projects
Is your feature request related to a problem? Please describe. In OpenTelemetry we use a mono-repo approach for our repos with shared common code/functionality. In the case of the collector we selectively choose components which are bundled into a single release binary and components can be in multiple release bundles. We are wanting to be able to have a changelog for each release binary which is scoped to only the components used.
Describe the solution you'd like The ability to when defining a project in config to also specify the available components to be included. These project components are a subset of the global components.
When a user is creating a changelog, they
- select the project or leave it empty
- select the component which is either the global list if no project was specified or project has no components. Otherwise user selects from project components. If left empty use project name.
- completes creation of unreleased changelog
The project batch process looks for unreleased changelog where the project matches or project is empty and component matches.
It should not be supported to batch a single project if it contains components.
Describe alternatives you've considered Making projects an array on the unreleased changelog file but breaking change and very verbose solution.
Additional context N/a
Hmm good point, not sure why components aren't per project. I think this type of behavior is a good reason to push more for the v2 config I was working on.
I would still keep components global but introduce the ability for them to be associated with one or more projects.
This way a component can appear in one or more projects which is something we would use. Scenario is if we bump the sdk being used for all projects, we could specify the component as "core" which is used in all projects.
I would still keep components global but introduce the ability for them to be associated with one or more projects.
This way a component can appear in one or more projects which is something we would use. Scenario is if we bump the sdk being used for all projects, we could specify the component as "core" which is used in all projects.
Right, I do something similar for kinds with the option to override the global values, the same would need to be possible at the project level. Like kinds per project as well. Or custom inputs per project.
Yeap both of those would be logical extensions to being able customise the experience based on the project.
Yeap both of those would be logical extensions to being able customise the experience based on the project.
Do you by chance have a public repo that you are trying to configure I could look at? Trying to get a sense of scope for the work, and use cases. I of course wanted changie to be extendable to a range of projects but when it comes to the upper end of that curve I am having a hard time seeing it.
So one of the more complex repo's is https://github.com/open-telemetry/opentelemetry-collector-contrib. that repo has many components and a component can be used in 1 or more projects.
With the mapping of component to project/distributiom seen in the sub pages of https://opentelemetry.io/docs/collector/components/
In effect the mapping of kind & custom inputs would not be needed for the use case as I understand hence could come later.
See https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/971 & https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/1317 for the request for otel to build this use case.
There is even https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/1199 to explore replacing the bespoke otel tool with an established oss tool. Solving this use case becomes a strong reason to switch as well as the fact it can easily be used for other languages in particular non go.
So one of the more complex repo's is open-telemetry/opentelemetry-collector-contrib. that repo has many components and a component can be used in 1 or more projects.
With the mapping of component to project/distributiom seen in the sub pages of opentelemetry.io/docs/collector/components
In effect the mapping of kind & custom inputs would not be needed for the use case as I understand hence could come later.
See open-telemetry/opentelemetry-go-build-tools#971 & open-telemetry/opentelemetry-go-build-tools#1317 for the request for otel to build this use case.
There is even open-telemetry/opentelemetry-go-build-tools#1199 to explore replacing the bespoke otel tool with an established oss tool. Solving this use case becomes a strong reason to switch as well as the fact it can easily be used for other languages in particular non go.
that is certainly some good info, and puts into a lot more context the requests. I am definitely willing to help out, some issues are definitely easier then others. Projects for example are a bit of a mess in implementation details for monorepos currently, so adding a lot more to that without some considerations would be less fun. I do have a v2 config design that better takes these things into account that I haven't really felt the need to push but maybe this is the path.
It is however very late for me and I have a bit of a deadline to meet, I will be around though.