Description

• A prerequisite for static type analysis of the transformation specification is that the types of input fields and output fields are available "AT COMPILE TIME" of the transformation specification. So, at this point, we do not have actual values for the CEL expressions yet.
• After we set up JSON an API to get the JSON schema for internal plugins (by generating it based on the Go types) and external plugins (they already provide their JSON schema during their discovery), we can implement a static type analysis a transformation specification.

Scope

• Generate JSON Schema for internal plugins
• Expose JSON Schema for both internal and external plugins
• Set up a basic transformation specification
• Implement a prototype for the transformation engine
  • Perform a static type analysis
  • Perform a basic evaluation of expressions

What to do:
JSON Schema

• Write a JSON schema generator for internal plugins that can convert runtime.Typed (for example, repositorySpec) and structures containing runtime.Typed (for example, download transformation - see ADR) to JSON schema.
• The type information (so, type name and aliases - oci, oci/v1, ociRegistry, ociRegistry/v1 have to be encoded into the JSON schema.
• Expose the JSON schema of external plugins

Engine

• Implement static type analysis. Build on the findings of last weeks spike to investigate static type analysis.
• Implement transformation evaluation. Build on ADR, on KRO RGD logic and on previous graph experience from construct.

Timebox
10 days

Done Criteria

• Code has been reviewed by other team members
• Analysis of existing tests (Unit and Integration)
• Unit Tests created for new code or existing Unit Tests updated
• Integration Test Suite updated (includes deletion of existing unnecessary Integration Test and/or creation of new ones if required)
• Enduser Documentation updated (if applicable)
• Internal technical Documentation created/updated (if applicable)
• Successful demonstration in Review