Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove internal data structure duplications to simplify the process of adding new field to the semconv registry. #208

Open
lquerel opened this issue Jun 12, 2024 · 0 comments

Comments

@lquerel
Copy link
Contributor

lquerel commented Jun 12, 2024

The current process of adding a new Semantic Convention Field is as follow.

Let's assume that you want to add the field display_name to the semantic convention groups. It's an optional field
containing a string that represents the display name of the group.

  1. Update the weaver_semconv crate to define the new field in src/group.rs. The
    data types defined in weaver_semconv are used to parse the registry YAML files. The following are some guidelines:
    • Optional field should be defined as Option<T>. So display_name should be defined as Option<String>.
    • N-ary fields should be defined as Vec<T>.
    • Other data types are also supported, such as bool, u64, f64, enum, HashMap, etc. The only constraint is
      that the type should implement the serde::Deserialize and serde::Serialize traits.
  2. Update the test data accordingly in weaver_semconv/data.
  3. Update all the unit tests to cover the new field. The easiest way to do this is to run the following command:
    • cargo test --package weaver_semconv
    • This command will run all the unit tests in the weaver_semconv crate.
    • The tests that fail will be the ones that need to be updated and usually the error message will guide you on what
      needs to be updated (most of the time it's the addition of the new field in some struct or enum initialization).
  4. Update the weaver_resolved_schema crate to add the corresponding new field in the "resolved" view of the registry.
    This crate define the data types used to represent the resolved view of the registry.
  5. Update the weaver_resolver crate to define the mapping between the "non-resolved" and "resolved" views of the
    registry.
  6. Update the weaver_forge crate to generate the new field in data structures used by the template engine.
  7. Update your templates to use the new field and use the weaver registry generate command to generate and test the
    new templates.

Steps 4 and 6 could be merged as step 6 doesn't really bring any new value in this context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant