Skip to content

Commit

Permalink
[chore] Add note to CONTRIBUTING.md about releasing new components (#…
Browse files Browse the repository at this point in the history
…33549)

When following the contributing docs for a new component, it was not
apparent that there are 2 separate builder configs that need to be
updated in order to release a component. While this is documented in the
*next* section (and as a comment under this repo's builder config), I
hope that adding this note to the main section on new components will
help others avoid the same mistake.

Co-authored-by: Alex Boten <[email protected]>
  • Loading branch information
damemi and codeboten authored Jun 14, 2024
1 parent 753ecfd commit eb40c47
Showing 1 changed file with 9 additions and 4 deletions.
13 changes: 9 additions & 4 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -164,10 +164,15 @@ and its contributors.
available configuration settings so users can copy and modify them as needed.
- Run `make crosslink` to update intra-repository dependencies. It will add a `replace` directive to `go.mod` file of every intra-repository dependant. This is necessary for your component to be included in the contrib executable.
- Add your component to `versions.yaml`.
- All components included in the distribution must be included in [`cmd/otelcontribcol/builder-config.yaml`](./cmd/otelcontribcol/builder-config.yaml)
and in the respective testing harnesses. To align with the test goal of the project, components must be testable within the framework defined within
the folder. If a component can not be properly tested within the existing framework, it must increase the non testable
components number with a comment within the PR explaining as to why it can not be tested.
- All components included in the distribution must be included in
[`cmd/otelcontribcol/builder-config.yaml`](./cmd/otelcontribcol/builder-config.yaml)
and in the respective testing harnesses. To align with the test goal of the
project, components must be testable within the framework defined within the
folder. If a component can not be properly tested within the existing
framework, it must increase the non testable components number with a comment
within the PR explaining as to why it can not be tested. **(Note: this does
not automatically include any components in official release binaries. See
[Releasing new components](#releasing-new-components).)**
- Create a `metadata.yaml` file with at minimum the required fields defined in [metadata-schema.yaml](https://github.com/open-telemetry/opentelemetry-collector/blob/main/cmd/mdatagen/metadata-schema.yaml).
Here is a minimal representation:
Expand Down

0 comments on commit eb40c47

Please sign in to comment.