CLOUDP-292850: Investigate diff approach for Metric Collection #346
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed changes
Jira ticket: CLOUDP-292850
PoC for Incremental Validation Framework
This PR introduces a Proof of Concept (PoC) for the Incremental Validation Framework, as outlined in the IPA Validation Framework Technical Design document
Key Findings and Implementation Steps:
Step 1: Splitting the Latest OpenAPI Version
The OpenAPI specification prior to the latest version is split by tags, with a separate file created for shared components.
Primary logic resides in
split_oas.go
.Step 2: Detecting Changes
Changes are identified and classified into three cases: added, deleted, and modified. Primary logic resides in
detect_changes.go
fileComponents Changes:
If any shared components are updated, the shared_components file must also be updated to reflect these changes.
This file is later merged with the tag-split files for affected paths.
Added Paths:
If new paths are identified, tag-split files should be updated accordingly.
If a directory with the corresponding tag name for new path doesn't exist, it will be created. Otherwise, the tag-related file is updated with the new path.
Assumption: All endpoints within a path share the same tag.
Deleted Paths:
Deleted paths are extracted from the split files and placed into a separate
deleted_spec.yaml
file.Spectral validation will not run on split files if they have no additions or updates. Additionally, a tag will not be recorded as
affectedTag
if its only change is the deletion of a path.All
deleted_spec.yaml
files will be merged with theshared_components.yaml
file. Results related to paths (but not components) in the merged file will be flagged asisDeleted=true
.Deleted Components (Not Implemented, as suggestion)
Components removed from the OpenAPI spec are extracted from the
shared_components
file and placed in adeleted_components.yaml
file.Spectral validation will be run on
deleted_components.yaml
file and results will be flagged asisDeleted=true
Modified Paths:
Affected tags are tracked, and only the corresponding split files are updated.
Step 3: Incremental Validation
Only the affected tag-split files are merged with the
shared_components.yaml
file.Spectral linting runs on merged files.
Future optimization: Components could be tailored to include only those referenced in the affected tag-split files.
Primary logic resides in
main.go
.Output Examples:
path_to_key_mapping.json:
Provides a mapping of paths to their corresponding keys, including updates from detected changes.merged_spec.yaml
: Demonstrates a merged specification for Monitoring and Logs tag-related paths along with the shared components file. This merge was necessary because the updated collectionName parameter is referenced in paths associated with the Monitoring and Logs tags. This file represents one of the merged outputs generated after detecting differences between the old and new versions.Notes on Running the Code:
Checklist
Changes to Spectral
Further comments