Skip to content

[Feature Request]: Align parameter files naming and scenarios #1564

@eriqua

Description

@eriqua

Description

Align on the different use cases we want to cover in our module tests and reflect that in the parameter naming convention. For instance:

  • modules covering multiple services should cover all test scenarios
    • e.g. cognitive services cover both speech and face services. parameter files should cover both use cases, hence include speech.parameters.json and face.parameters.json
  • always include a min.parameters.json to cover only required parameters. For modules covering multiple services this could be duplicated if different services lead to different implementations.
    • e.g. cognitive services cover both speech and face services. parameter files should cover both use cases, hence include speech.min.parameters.json and face.min.parameters.json
  • all modules providing cmk functionality should include a encr.parameters.json (or cmk.parameters.json). For modules covering multiple services this could be duplicated if different services lead to different implementations.

    Discussion needed: we could go for either a "always use encr.parameters.json" for consistency and to clearly show shorter specific examples in the readme or "use it only if required due to incompatibility with other settings" to instead try to include all possible features in the main parameters.json. The latter approach would probably be preferable considering the new dependencies approach. In either case update the Wiki as needed.

  • all modules providing networking functionalities ahould include a net.parameters.json (or similar). For modules covering multiple services this could be duplicated if different services lead to different implementations.

    Discussion needed: same as above.


Update: this is now related to main.test.bicep wrapper modules

Metadata

Metadata

Assignees

No one assigned

    Labels

    [cat] modulescategory: modulesdocumentationImprovements or additions to documentationenhancementNew feature or request

    Type

    No type

    Projects

    Status

    Done

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions